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ABSTRACT 


-V 

This  thesis  is  a  detailed  design  of  a  security  kernel 
for  an  archival  file  storage  system.  Microprocessor 
technology  is  used  to  address  a  major  part  of  the  problem 
of  information  security  in  a  distributed  computer  system. 
Utilizing  multiprogramming  techniques  for  processor 
efficiency,  segmentation  for  controlled  sharing,  and  a 
loop-free  structure  for  avoiding  intermodule  dependencies, 
the  Archival  Storage  System  is  designed  for  implementation 
on  the  Zilog  Z3001  microprocessor  with  a  memory  management 
unit.  The  concepts  of  a  process  structure  and  a 
distributed  kernel  are  used  in  providing  management  of  the 
shared  hardware  resources  of  the  system.  The  security 
kernel  primitives  create  a  virtual  machine  environment  and 
provide  information  security  in  accordance  with  a 
non-discreticnary  security  policy. 
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I.  INTRODUCTION 


This  detailed  design  of  a  security  kernel  provides  a 
basis  for  implementation  of  an  archival  file  storage 
operating  system.  The  system  is  intended  to  store  files 
for  an  array  of  computer  hosts  at  multiple  information 
security  levels.  The  design  presents  algorithms  and  data 
structures  which  can  be  implemented  on  microprocessor 
hardware  available  today,  to  provide  economical  and  secure 
storage.  Controlled  sharing  of  information  and  multilevel 
security  were  the  key  design  goals.  Multiprogramming  is 
the  technique  used  to  improve  efficiency  of  the  system 
which  is  primarily  performing  input  and  output  operations. 
A  loop-free  structure  is  used  to  avoid  undesirable 
dependency  loops  [1].  This  allows  modules  to  be  changed 
without  introducing  changes  in  other  modules. 

There  are  two  components  of  the  Archival  Storage 
System:  1)  the  Supervisor  and  2)  the  Security  Kernel  [2]. 
The  Supervisor  (the  subject  of  separate  research  [3]) 
supports  all  user  services:  1)  hierarchical  file  system, 
2)  discretionary  access  controls,  and  3)  protocols  for 
communication.  The  Supervisor  operates  outside  the  Kernel 
domain  on  a  virtual  machine  created  by  the  Kernel 
primitives.  The  Supervisor's  privilege-restricted  domain 
has  access  only  to  a  subset  of  the  machine  instructions, 
thus  needing  the  Kernel  primitives  to  accomplish  tasks 
such  as  input  or  output. 

The  Security  Kernel  described  in  this  thesis  manages 


the  real  resources  of  the  hardware  system:  1)  memory,  2) 
microprocessor,  3)  external  devices,  and  4)  input/output 
ports.  It  is  also  responsible  for  mediating  all 
non-discretionary  access  to  information.  The  Kernel 
operates  in  the  most  privileged  domain  of  the  machine  and 
therefore  has  access  to  all  machine  instructions. 

A.  3ACKGH00ND 

Microprocessors  have  become  affordable,  prolific,  and 
powerful  computing  resources.  The  result  of  these 
attributes  is  the  use  of  microprocessors  in  applications 
previously  requiring  much  larger  and  more  expensive 
processors.  Additionally,  new  applications  which  can  now 
be  economically  computerized  are  being  seriously  explored. 

Conversely,  software  has  become  more  costly. 
Microprocessor  operating  systems  and  applications  programs 
continue  to  be  highly  specialized,  thus  failing  to 
reasonably  exploit  the  potential  of  the  microprocessor. 
The  specialization  of  software  for  microprocessors  also 
perpetuates  problems  such  as  I/C  format  incompatibilities 
which  occur  when  information  exchange  among  processors  is 
desired . 

Information  security  on  microprocessors  has  been 
completely  ignored  to  date,  or  handled  with  ad-hoc 
attempts  at  a  solution.  However,  this  issue  is  becoming 
increasingly  important  as  the  uses  of  microprocessors 
continue  to  be  expanded.  Tor  example,  the  Department  of 
the  Navy  is  investigating  the  use  of  microprocessors  on 
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small  ships  for  automating  shipboard.  administrative 
functions  [4],  Information  security  for  such  functions  is 
a  major  requirement  which  cannot  presently  be  met. 

Proposing  a  solution  to  the  above  problems,  a 
high-level  design  for  a  secure  operating  system  for 
microprocessor-based  systems  has  been  outlined  by 
O'Connell  and  Hichardson  [5].  The  design  goals  of  that 
operating  system  were  configuration  independence, 
distributed  processing,  multiple  protection  domains, 
multiprocessing,  and  multiprogramming.  Because  such  a 
broad,  general  operating  system  is  not  always  reauired, 
the  design  provided  for  a  family  of  operating  systems.  A 
family  member  could  use  a  subset  of  functions  for  a 
specific  application  while  allowing  later  extensions.  This 
thesis  presents  the  detailed  design  for  such  a  family 
member . 

B.  BASIC  CONCEPTS 

The  Archival  Storage  System  can  be  the  nucleus  of  a 
secure,  distributed  multiprocessor  system.  It  provides 
’data  warehouse'  facilities  for  multiple  host  computers  in 
the  network.  A  host  may  be  operating  at  a  single  security 
level,  or  simultaneously  at  several  security  levels 
without  affecting  the  Archival  Storage  System.  Information 
storage  with  multilevel  security  is  provided  for  each  host 
connected  to  a  port  of  the  warehouse.  Additionally,  the 
data  warehouse  is  the  mechanism  for  providing  controlled 
sharing  among  the  hosts.  Thus,  we  can  apply  microprocessor 
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technology  to  address  a  significant  part  of  the  larger 
multilevel  security  problem  [6]  for  distributed  systems. 

A  subset  of  the  O'Connell  and  Richardson  design  has 
been  selected  as  the  basis  for  the  detailed  design  of  the 
Archival  Storage  System.  (The  subset  chosen  omits  the 
provisions  for  multiprocessors,  dynamic  linking,  demand 
segmentation,  "trar.s  lent”  processes,  and  a  user  domain.) 
The  Supervisor,  protocols,  and  interfaces  to  the  host 
computers  are  presented  in  a  parallel  thesis  by  Parks  [3] 
while  detailed  design  of  the  Security  Kernel  is  presented 
in  this  thesis-. 

There  are  two  components  of  the  Archival  Storage 
Sys tern  Security  Kernel  which  reside  in  the  pri vi leged 
domain  of  the  machine:  1 ) the  distributed  kernel  and  2)  the 
kernel  processes.  From  a  logical  view,  some  kernel 
procedures  are  distributed  among  all  the  Supervisor 
processes  in  the  system,  with  the  remaining  procedures 
forming  kernel  processes.  These  kernel  processes  perform 
functions  that  are  asynchronous  to  the  supervisor 
processes  and  are  responsible  for  the  shared  resources  of 
the  system  (processes,  processor,  memory,  input/output). 

1 .  Definition  of  a  Process 

A  sequential  process  can  be  conceptualized  as  an 
execution  point  and  an  address  space  which  is  a  logical 
rather  than  physical  entity.  All  procedures  that  are  in 
the  flow  (or  locus)  of  control  are  in  the  address  space. 
In  a  distributed  operating  system,  the  locus  of  execution 
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includes 


those  operating  system  functions  which  are 
logically  part  of  the  user  process.  The  distributed 
operating  system  is  divided  into  procedures  which  are 
called  in  normal  fashion,  but  are  located  in  the 
privileged  domain. 

2 .  Multiple  Protection  Domains 

One  requirement  for  design  of  a  security  kernel  is 
isolation  of  the  kernel  procedures  to  make  them 
tamperproof.  A  way  this  can  be  achieved  is  to  arrange  the 
process  address  space  into  hardware  or  software  protection 
domains.  Domains  need  not  be  hierarchical,  but  in  this 
case  they  are.  Hierarchical  domains  are  commonly  called 
protection  rings  [?] . 

2ach  level  in  the  hierarchy  is  more  privileged 
than  the  preceding  level.  In  the  Archival  Storage  System 
only  two  domains  are  necessary.  Other  levels  must  be  added 
to  protect  the  Supervisor  if  the  design  is  extended  to 
include  user  applications.  The  distributed  kernel  resides 
in  the  most  privileged  domain  and  may  access  any  segment 
within  the  address  space  of  a  process.  All  systemwide 
databases  are  in  the  kernel  domain.  Violation  of  the 
confinement  principle  described  by  Lampson  [9]  and  Lipner 
[9]  would  occur  if  such  information  could  be  passed  to 
other  domains. 

Th°  Supervisor  operates  in  the  outer  or  least 
privileged  protection  domain  where  access  to  segments  and 
external  devices  is  restricted.  Only  those  databases  which 
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are  ’’process  local"  may  be  accessed.  This  does  not  prevent 
sharing  since  different  segment  numbers  and  access  rights 
for  each  process  can  be  interpreted  and  enforced  by  the 
kernel.  Each  Supervisor  process  is  required  to  remain  at  a 
specified  security  level  within  its  domain. 

Protection  domains  may  be  created  by  either 
hardware  or  software.  Software  implementations  of 
protection  domains  (as  in  the  early  Multics  [12])  are 
feasible,  but  result  in  a  degradation  of  efficiency.  This 
performance  loss  is  unacceptable  in  many  applications.  In 
large  processors  a  hardware  ring  mechanism  is  sometimes 
used  to  provide  the  implementation  [7]  .  This  general  ring 
mechanism  is  not  available  in  current  microprocessors,  but 
two  domain  machines  are  available.  When  supplemented  by 
ring-crossi ng  software,  this  will  provide  the  desired 
multiple  domains. 

3 .  Segmentation 

A  segment  is  defined  as  a  logical  grouping  of 
information  [ill ,  while  segmentation  is  a  technique  for 
managing  segments  within  an  address  space.  A  process's 
address  space  consists  of  a  collection  of  procedures  and 
data  segments.  All  address  specifications  require  the 
segment  specification  and  the  offset  within  the  segment 
(i.e.,  a  two-dimensional  address).  Segments  are  therefore 
distinctly  visible  to  the  user.  Unlike  pages,  segments  are 
arbitrarily  sized  and  logical  units  with  logical 
attributes  to  describe  them. 
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Attributes  of  segments  are  contained  in  a 
structure  called  a  segment  descriptor.  The  descriptor 
associates  segments  with  address  in  memory,  size,  and 
access  allowed.  Maintaining  all  of  the  descriptors  of  the 
segments  of  a  process  in  a  descriptor  list  allows  the 
address  space  of  the  process  to  be  easily  managed. 

Segmentation  offers  benefits  as  a  memory 
management  scheme.  The  key  advantage  is  the  ability  of 
multiple  processes  to  share  segments  without  the 
requirement  of  maintaining  multiple  copies  in  memory. 
Cther  favorable  characteristics  of  segmentation  are 
control  of  memory  waste  due  to  fragmentation,  creation  of 
user  virtual  memory,  dynamic  linking  of  modules,  and 
enforcement  of  controlled  segment  access. 

Segmentation  eliminates  the  need  to  duplicate  a 
segment  when  shared.  Having  only  one  copy  saves  memory  and 
eliminates  the  problem  of  conflicting  data  which  occurs 
when  multiple  copies  are  maintained.  Even  more  central  to 
segmentation  is  the  ability  of  cooperating  processes  to 
communicate  with  each  other  through  shared  segments. 
Inter-process  synchronization  and  communication  are 
necessary  functions  in  a  mul tiprogramming  environment. 

4 .  Information  Security 

Most  users  of  computer  systems  are  required  to 
safeguard  information  from  unauthorized  access.  Examples 
abound:  government  'classified  information),  corporations 
(trade  secrets),  banking  (electronic  funds  transfer),  and 
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all  users  of  personal  data  (privacy  act).  This  reauirement 
is  not  relaxed  when  microprocessors  are  used  instead  of 
(or  in  support  of)  large  computer  systems.  Dedicating  a 
device  to  a  specific  security  level  (dedicated  mode)  [51 
is  a  method  commonly  used  to  meet  the  security 
requirement.  This  solution  is  unsatisfactory  for  any  user 
with  a  reauirement  to  utilize  data  at  more  than  one  access 
class  . 

Another  solution  to  the  problem  of  accessing 
information  at  different  security  levels  is  to  operate  in 
the  multilevel  mode.  In  this  case  both  users  and 
information  at  different  security  classes  exist 
simultaneously  on  the  same  computer  system.  Users  are  not 
permitted  to  access  information  unless  authorized  by  the 
security  policy  in  effect. 

In  the  dedicated  mode  all  security  measures  are 
external  to  the  computer  system  (e.g.,  perimeter  fencing, 
guards,  door  locks,  etc.).  When  a  multilevel  mode 
environment  is  used,  controls  must  be  internal  as  well  as 
external.  Attempts  at  internal  controls  have  been  tried  by 
adding  security  measures  to  existing  systems  with 
unsatisfactory  results.  Numerous  cases  are  documented  of 
penetrations  (l.e.,  unauthorized  access)  of  these  systems 
[5]  .  Intuition  rather  than  sound  design  was  the 
methodology  used  in  these  unsuccessful  attempts  at 
securi ty . 

Internal  controls  must  be  designed  into  a  system 


from  its  conception.  The  approach  to  designing  these 
controls  is  the  security  kernel  methodology.  The  first 
step  using  the  security  kernel  methodology  is  to  define 
the  security  requirements.  From  this  definition  a 
conceptual  design  is  created.  The  conceptual  design  is 
actually  a  mathematical  model  which  can  he  rigorously 
proven  and  provides  the  basis  for  testing  (certifying)  [2] 
all  subseauent  implementations. 

Three  things  are  reouisite  before  a  system  can  be 
secure  using  the  security  kernel  concept:  1)  The  kernel 
must  be  isolated  or  tamperproof.  Obviously  if  a  penetrator 
can  change  the  kernel  software,  then  the  behavior  of  the 
kernel  can  be  modified.  2)  The  kernel  must  be  invoked  on 
every  attempt  to  access  information.  This  requirement  can 
be  met  by  initial  software  interpretation  of  access  on  the 
first  call  to  a  segment.  Thereafter,  hardware  can  enforce 
the  access  criteria.  3)  The  kernel  must  be  subject  to 
certification.  Proof  of  the  mathematical  model  must  be 
followed  by  thorough  testing  of  the  implementation  to 
insure  that  each  input  yields  the  desired  output.  Since 
hardware  and  software  are  involved,  both  must  be  tested 
before  the  kernel  car.  be  certified. 

As  previously  stated,  the  first  step  in  the  design 
of  the  secure  computer  system  is  to  define  the  security 
requirements.  A  properly  designed  computer  system  is  then 
secure  with  respect  to  that  definition  or  policy.  A 
security  policy  consists  of  the  external  laws,  rules,  and 


regulations  that  establish  what  access  is  to  be  permitted. 
Two  distinct  types  of  security  policy  exist:  1) 
ncn-discretionary  and  2)  discretionary. 

Non-discreti onary  policy  involves  comparing  the 
requested  (i.e.,  the  information  object's)  access  class 
(oac)  with  the  access  class  of  the  requestor  (i.e.,  the 
subject)  (sac)  to  insure  that  they  are  compatible.  For 
example,  in.  the  Department  of  Defense  security  policy  a 
secret  cleared  individual  (subject)  may  have  access  to 
documents  (objects)  which  are  classified  as  secret, 
confidential,  or  unclassified. 

The  relationships  between  different  access  classes 
can  be  represented  by  a  lattice  structure  [12].  This 
lattice  structure  is  totally  ordered  if  all  classes  are 
related.  When  the  classes  are  either  related  or  disjoint 
the  lattice  is  partially  ordered.  The  lattice  structure 
interprets  the  authorized  access  based  on  the 
relationships  between  two  labels.  The  lattice  structure 
abstraction  is  important  because  it  seems  to  represent 
most  practical  security  policies.  3y  changing  the 
interpretation  of  labels  in  the  non-discretionary  security 
module,  a  different  policy  can  be  implemented  so  that,  for 
example,  Privacy  Act  requirements  are  as  enforceable  as 
Department  of  Defense  security  policies. 

The  following  interpretation  defines  the  access 
-ermitted  in  a  computer  system  (where  "%"  is  defined  to 
mean  unrelated)  in  terms  of  subject  access  class  (sac)  and 
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object  access  class  (oac): 

sac  =  oac,  read/write  permitted 
sac  >  oac,  read  permitted  (read  down) 
sac  <  oac,  write  permitted  (write  up) 
sac  %  oac,  no  access 

DOD  security  policy  is  represented  by  a  partially  ordered 
lattice  since  security  classifications  are  composed  of  a 
classification  level  and  a  category  (e.g.,  secret, 
cryptographic  or  confidential,  nuclear). 

Discretionary  controls  provide  a  refinement  of  the 
non-discretionary  access.  A  common  example  of 
discretionary  controls  involves  checking  an  access  control 
list  before  allowing  an  access.  This  allows  authorized 
subjects  ,users)  to  specify  who  may  use  that  segment 
within  the  confines  of  the  non-discretionary  policy.  The 
DCS  "need-to-kncw"  rule  is  an  example  of  discretionary 
policy.  In  the  Archival  Storage  System  non-discretionary 
policy  is  enforced  by  the  Supervisor,  based  on  both  the 
host  and  the  user. 

C.  STRUCTUR3  CP  THP  TSPSIS 

This  thesis  presents  the  detailed  design  of  a  portion 
of  the  security  kernel  for  an  archival  file  storage 
facility  (distributed  kernel  procedures  and  memory  manager 
process).  Levels  of  abstraction  are  used  to  reduce  the 
complexity  of  the  hierarchical  Archival  Storage  System. 
Level  2  contains  the  Supervisor  and  operates  in  the 
virtual  environment  created  by  the  kernel.  The  Supervisor 
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does  not  control  the  hardware  of  the  system  hut  applies 
the  hardware  resources  only  hy  appealing  to  the  functions 
of  the  Kernel.  Calls  to  procedures  at  different  levels  may 
only  he  made  in  a  downward  direction  and  corresponding 
returns  only  in  an  upward  direction  (i.e.,  the  Kernel  may 
not  call  upon  the  Supervisor  to  accomplish  any  task).  This 
restriction,  rigidly  enforced  at  all  levels  of  abstraction 
in  the  design,  reduces  the  number  and  type  of  interactions 
of  the  system. 

Figure  1  shows  the  process  structure  of  the  system 
with  the  distributed  and  non-di st ributed  kernel.  The 
asynchronous  Memory  Manager  and  I/O  Manager  are  kernel 
processes.  The  remaining  kernel  procedures  are  distributed 
in  all  the  supervisor  processes. 

In  the  next  chapter  the  details  of  the  design  are 
presented.  Although  this  is  not  an  implementation,  the 
Zilog  Z6001  Microprocessor  [13]  with  the  ZS012  MMU  Memory 
Management  Unit  is  used  as  the  hardware  base  for  this 
research.  Choices  made  during  the  design  process  were 
often  influenced  by  the  hardware  features  available.  The 
ZS000  family  of  devices  is  not  mandatory  for  implementing 
the  Archival  Storage  System.  Other  microprocessors  exist 
which  are  capable  of  supporting  a  secure  system. 

Algorithms  and  data  structures  are  presented  in  tne 
high  level  language  PLZ/ST5  [14]  .  PLZ/SYS  is  a 
Pascal-like,  blcck-s tructur<=d  language,  resigned  by  Zilog, 
the  language  can  be  compiled  to  ZS000  instruction  code. 
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Figure  l.  Process  View 
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PLZ/ASM  [15]  is  used  where  machine  level  instructions  for 
direct  hardware  manipulation  are  required.  These  two 
languages  for  the  Z3000  are  used  because  of  the  capability 
of  linking  modules  of  either  language  to  the  other. 
Additionally,  PLZ/ASM  has  the  same  high  level  data 
structures  and  structured  control  mechanisms  present  in 
PLZ/STS. 

The  conclusions  reached  during  this  research  are 
presented  in  the  last  chapter.  Topics  for  further  research 
and  implementation  are  identified,  including  those  in  the 
area  of  secure  systems.  With  this  multilevel  data-store,  a 
secure  distributed  microprocessor  system  can  be 
implemented  using  communications  lines  to  interface 
distributed  processors  of  the  network  to  the  "data 
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II.  DETAILED  DESIGN 


A.  HARDWARE  REQUIREMENTS 

Theoretically  a ay  processor  hardware  is  usable  for 
secure  computer  systems.  However,  in  practice  certain 
hardware  features  are  essential  for  efficiency.  In 
addition,  complexity  of  the  software  portion  of  the 
security  kernel  is  highly  dependent  upon  the  capabilities 
of  the  hardware.  Because  simplification  of  the  kernel 
results  in  an  easier  proof  of  correctness,  it  is 
worthwhile  to  use  additional  hardware  to  achieve  security. 

One  essential  hardware  feature  is  a  segmentation 
mechanism.  Segmentation  allows  the  use  of  one  uniform  type 
of  information  object,  the  segment.  Kernel  software  which 
deals  with  logical  objects  is  then  simplified.  Paging 
hardware  without  segmentation  does  not  provide  a  correct 
structure  for  objects,  since  pages  are  physical  objects 
with  physical  attributes.  For  example,  an  access  right  is 
a  logical  attribute.  Applying  an  access  right  to  a 
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A  segment  address  consists  of  a  segment  name  and  an 
offset  within  the  segment.  This  logical  address  must  be 
transformed  into  an  absolute  address  before  it  can  be 
used.  While  software  is  capable  of  making  this 
transformation,  hardware  can  perform  the  mapping  more 
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efficiently  and  simultaneously  check  access  while  doing 
the  mapping. 

Multiple  execution  domains  are  also  considered 
essential  in  hardware.  This  feature  is  used  in  current 
computer  systems  to  protect  the  operating  system  from 
applications  programs,  hut  until  recently  this  feature  has 
not  been  available  in  microprocessor  hardware.  In  the 
initial  Archival  Storage  System  implementation  only  two 
domains  are  necessary  since  applications  programs  do  not 
exist  inside  the  boundaries  of  the  system.  Protecting  the 
Kernel  from  the  Supervisor  is  the  only  domain  protection 
required.  If  user  utilities  are  added  to  the  design,  then 
another  domain  will  be  necessary  to  protect  the  Supervisor 
from  user  tampering. 

With  the  introduction  of  Zilog's  Z3000,  the  above 
hardware  features  are  available  in  the  microprocessor 
category.  The  design  of  the  Archival  Storage  System  is 
targeted  toward  a  hardware  system  based  upon  the  Z8001 
segmented  microprocessor  [16]  and  the  ZS010  MMU  Memory 
Management  Unit  [17] .  The  Z8001  is  a  16-bit  two-domain 
microprocessor  which  produces  a  23-bit  segmented  address. 
The  Z3010  MMU  maps  the  23-bit  logical  address  into  a 
24-blt  absolute  address  and  allows  the  capability  of 
addressing  up  to  12S  segments  of  64E  bytes  each  in  the 
two-dimensional  memory  space. 

In  addition  to  the  address  mapping  hardware,  the  MMU 
also  provides  memory  access  protection.  Segment  access  may 
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be  set  to  write  (read,  implied),  read,  or  execute  only. 
When  an  unauthorized  access  is  attempted,  the  MMU  prevents 
the  access,  then  sends  a  trap  (or  fault)  signal  to  the 
microprocessor.  A.  trap  is  an  internal  interrupt  which  is 
synchronous  rather  than  asynchronous  to  the  cycling  of  the 
processor  and  must  he  resolved  by  the  processor  before 
processing  can  continue. 

The  microprocessor  also  supports  two  protection 
domains.  The  MMU  provides  the  implementation  of  two 
hardware  rings  by  checking  for  system  or  user  status  on 
each  access  to  a  segment.  The  bit  in  the  MMU  which 
specifies  system  or  normal  mode,  thus  specifies  which 
segments  are  accessible  in  just  the  Kernel  ring  and  which 
segments  are  also  accessible  in  the  Supervisor  ring.  Thus 
a  process  must  cross  into  the  Kernel  ring  to  access  the 
Kernel  primitives.  If  more  than  two  rings  are  required,  an 
additional  MMU  (up  to  eight  total)  may  be  employed  per 
r  ing . 

The  hardware  also  supports  resource  control  by 
limiting  the  use  of  certain  machine  instructions.  In  the 
system  mode  all  machine  instructions  can  be  executed.  When 
in  user  mode,  the  hardware  will  not  allow  the  use  of 
input/cutput  instructions,  certain  machine  control 
instructions,  or  special  input/output  instructions  (used 
to  load  and  control  the  MMU).  Thus  the  Kernel  can  control 
the  microprocessor,  the  main  memory  (through  the  MMU),  and 
all  external  devices. 


Hardware  features  other  than  those  described  above  are 
indicated  from  a  oerformance  standpoint.  For  instance,  a 
direct  memory  access  (DMA)  device  could  make  memory  to 
memory,  memory  to  port,  or  port  to  memory  transfers  faster 
than  similar  transfers  under  direct  CPU  control.  This 
would  allow  the  CPU  to  continue  with  other  tasks  while  the 
DMA  is  processing  the  data  transfers.  Protection  of  memory 
can  still  be  realized  by  routing  the  DMA  through  the  MMU. 
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guarantee,  by  MMU  set-up,  that  the  DMA  would  not  violate 
the  securi ty  policy.  This  type  of  hardware  is  not  crucial 
to  the  design  at  this  level,  and  the  decision  on  its  use 
is  left  to  the  implementor. 

The  MMU  does  lack  a  descriptor  base  register 
capability  [101  .  Process  switches  without  this  facility 
require  at  least  selective  unloading  and  loading  of  the 
descriptor  registers  in  the  MMU,  and  a  process  switch 
would  take  roughly  two  (2)  milliseconds  to  accomplish  in 
this  manner.  It  is  evident  that  process  switching  may  lead 
to  thrashing  problems  if  done  too  often.  There  are  ways 
the  implementor  might  avoid  this  problem  (e.g.,  dedicating 
an  MMU  to  each  process,  then  switching  MMUs  rather  than 
loading/unload ing  a  single  MMU). 

3.  PROPOSED  KIP MEL  DESIGN 

1 .  Notation 

Notation  is  important  in  making  algorithms 
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understandable.  It  should  not,  however,  require  more 
thought  to  understand  the  notation  than  the  central 
concept.  Since  this  thesis  presents  a  detailed  design,  a 
notation  as  close  as  possible  to  an  actual  language  which 
can  compile  to  ZS000  machine  code  was  desired.  PLZ 
languages  are  used  as  a  notation  to  illustrate  the  data 
structures  and  procedures.  However,  the  code  as  shown  in 
the  figures  cannot  be  directly  implemented.  Among  other 
changes,  procedure  order  has  been  rearranged  to  make 
explanation  of  the  modules  more  logical.  This  change  would 
violate  a  PLZ/SYS  implementation  rule  that  procedures  must 
be  declared  before  they  can  be  invoked. 

The  details  of  the  actual  PLZ/SYS  language 
implementation  may  be  different  from  that  assumed  in  this 
thesis.  In  particular,  the  specific  method  of  parameter 
passing  between  PLZ/ASM  and  PLZ/SYS  is  unknown  at  this 
time.  The  implementor  should  carefully  investigate  how 
passing  of  parameters  in  the  actual  language 
implementation  affects  the  interfaces  between  modules. 

Because  of  the  terminology  used  in  the  ZS000 
Microprocessor  specifications,  the  Supervisor  may  be 
referred  to  as  operating  in  the  normal  or  user  mode.  If 
the  term  system  mode  is  used,  it  refers  to  the  Kernel 
domain  of  execution. 

2 .  Kernel  Overview 

The  distributed  Kernel  modules  exist  on  three 
levels  (figure  2).  Each  module  creates  a  different  level 
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Figure  2.  Hierarchical  View 
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of  abstraction  [19].  At  level  1  or  the  innermost  level  is 
the  Inner_Traf f ic_Controller .  Its  primary  task  is  the 
control  of  virtual  processors  and  the  multiplexing  of 
virtual  processors  onto  the  real  processor.  The 
Inner_Traff ic_Contro Her  uses  the  Virtual  Processor  Table 
as  a  management  tool  for  this  multiplexing  of  virtual 
processors . 

At  level  2  is  the  Traf f ic_Controller .  The 
Traffic_Coctroller  creates  the  sequent ia 1  process 
abstraction  [17].  A  process  can  be  in  one  of  two  states: 
1)  blocked  or  2)  unblocked.  When  blocked,  it  must  wait  for 
the  occurrence  of  some  event.  Since  the  process  cannot 
proceed  until  that  event  occurs,  the  virtual  processor  is 
freed  and  then  allocated  to  another  process.  When 
unblocked  a  process  is  either  ready  or  running.  In  the 
ready  state,  the  process  can  run  when  a  virtual  processor 
is  assigned  to  it.  The  readv  state  can  be  entered  from 
either  the  running  or  blocked  state  (figure  3). 

The  Non_Discretionary_Securi ty  Module  is  also  on 
level  2.  This  module  is  charged  with  interpretation  of  the 
security  policy  in  effect.  It  compares  the  two  labels 
which  are  passed  to  it  and  determines  the  relationship  of 
the  labels  based  on  a  lattice  structure  known  to  the 
module.  This  relationship  is  then  used  by  the  kernel  to 
determine  authorized  access  to  objects  (segments  or 
parts).  It  is  emphasized  that  the  Kernel  makes  decisions 
about  access  based  on  relationships  (=,  <,  >,  not  related) 
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and  not  on  the  labels  themselves.  The 
Non_Discretionary_Security  Module  is  the  only  -nodule  in 
the  Kernel  which  makes  any  interpretation  of  security 
labels.  This  allows  most  of  the  practical  security 
policies  to  be  implemented  simply  by  changing:  the 
Mon_Discret ionary_Security  Module. 

At  level  3  is  the  Segment_Manager .  Using  the  MMU 
mapping  to  real  memory  provided  by  the  hardware,  the 
3egment_Manager  creates  a  segmented  virtual  memory  for  the 
process.  Because  of  the  limitations  of  the  hardware  (lack 
of  a  paging  mechanism),  segments  are  not  dynamically 
allocated  real  memory.  The  size  of  a  reauested  segment  is 
fixed  (or  determined)  at  the  time  it  is  created  and  may 
not  change.  The  Supervisor  has  several  options  in  order  to 
handle  the  problem  of  growing  segment  size:  1)  Allocate 
the  maximum  size  to  every  segment  which  is  wasteful  of 
memory,  2)  copy  the  segment  into  a  larger  segment  whenever 
the  size  changes  which  is  wasteful  of  processor  cycles,  3) 
create  a  "super-segment"  as  a  collection  of  segments,  or 
4)  some  combination  of  the  above.  3y  requiring  the 
Supervisor  to  handle  this  problem,  the  initial  Kernel 
implementation  is  simpler. 

The  whole  segment  must  be  swapped  into  main  memory 
in  order  to  be  used.  The  MMU  supports  segments  ranging  in 
size  from  256  bytes  to  64K  bytes  in  multiples  of  256 
oytes  .  Additionally,  the  hardware  forces  another 
constraint  on  the  design.  Without  paging,  two  allocation 
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schemes  are  available  to  the  designer:  1)  a  demand 
segmentation  memory  management  scheme  (load  the  segment  in 
response  to  a  fault)  or  2)  a  partitioned  allocation 
scheme.  In  this  desisn  a  partitioned  allocation  scheme  is 
used  to  make  the  Kernel  less  complex.  Part  of  the  burden 
of  memory  management  is  then  forced  on  the  Supervisor.  The 
Supervisor  of  each  process  is  given  a  fixed  amount  of 
linear  'virtual  core'.  Linear  'virtual  core”  is 
distinguished  from  the  two-dimensional  virtual  memory 
created  by  the  segmentation.  The  Supervisor,  by  requests 
to  the  Kernel,  may  fill  virtual  core  with  segments  as  it 
chooses.  The  Supervisor  of  each  process  must  manage  its 
own  virtual  core  and  fit  any  segments  it  uses  within  the 
boundaries  of  this  virtual  core.  The  partitioned 
allocation  portion  of  the  memory  management  scheme  is 
supported  by  the  Memory_Manager  process  of  the 
non-dist ributed  Kernel. 

The  non-distributed  portion  of  the  Kernel  resides 
in  two  kernel  processes:  1)  Memory_Manager  and  2) 
I/0_Manager.  These  two  processes  are  responsible  for 
actions  which  are  not  logically  part  of  the  supervisor 
processes  because  they  can  function  asynchronously  to  the 
processes.  The  Memory Manager  moves  segments  within  the 
physical  memory  space  of  the  system.  These  transfers  may 
be  main  memory  to  main  memory,  main  memory  to  secondary 
storage,  or  secondary  storage  to  main  memory.  Main  memory 
to  main  memory  -roves  are  made  because  of  a  design  decision 
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to  restrict  sharing  of  the  sane  copy  of  a  segment  unless 
at  least  one  of  the  sharins  processes  has  write  permission 
to  the  segment,  'whenever  two  processes  share  a  segment  and 
neither  has  write  access,  two  copies  of  the  segment  will 
exist — one  in  each  virtual  processor  local  memory.  This 
trade-off  results  in  less  complexity  in  the  kernel  and 
when  the  design  is  expanded  to  a  multiprocessor 
implementation,  bus  contention  is  minimized  [5].  The 
problems  associated  with  the  existence  of  multiple  copies 
in  memory  are  not  present  since  the  segment  is  not 
wri teable . 

Whenever  a  segment  is  to  be  shared  and  is 
writeable,  then  the  segment  must  be  moved  to  the  real 
processor  global  memory.  Movement  of  the  segment  is  easily 
accomplished  by  updating  the  appropriate  f'fUs  to  reflect 
the  new  location  of  the  segment.  This  concept  of  a  process 
local  and  global  memory  is  analogous  to  processor  local 
and  global  memories  in  multiprocessor  systems.  In  those 
systems,  each  real  processor  owns  a  local  memory,  while 
the  system  controls  the  global  memory  used  by  all 
processors  for  shared  information. 

The  I/0_Manager  is  responsible  for  routing 
segments  across  the  system  boundary,  viz.,  moving  data 
between  external  ports  of  the  system  and  main  memory.  The 
I/Cjdanager  does  not  try  to  interpret  the  data,  but  simply 
provides  a  transfer  service.  All  the  ports  have  specific 
security  classifications  and  are  hard-wired.  This  allows 
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the  I/0_Manager  to  function  without  requiring  labels  or 
other  security  mechanisms  to  determine  access  class. 
Having  all  Hosts  at  a  fixed  security  level  is  a  design 
choice  for  the  Archival  Storage  System.  Hosts  can  be  at 
multiple  levels  if  the  design  is  modified  to  accept 
"trusted"  labels.  In  the  present  design  the  Host  computer 
is  reauired  to  be  at  the  level  of  the  port  and  to  handle 
data  consistent  with  the  security  policy  in  effect. 

Since  the  hardware  does  not  completely  support  the 
ring  structure,  software  (Gate_Keeper )  is  needed  for  the 
ring-crossing  mechanism  and  thus  isolation  of  the  Kernel. 
All  calls  to  the  distributed  Kernel  and  interprocess 
communication  with  the  non-di stributed  Kernel  from  the 
Supervisor  must  pass  through  the  Gate_Keeper.  The  function 
of  the  Gate_Keeper  is  to  provide  the  sole  entry  point  or 
gate  into  the  Kernel  ring,  validate  the  call  and 
arguments,  and  transfer  the  call  to  the  appropriate  Kernel 
module.  If  a  call  is  made  incorrectly  the  Gate_Keeper  sets 
a  return  message  to  an  error  code,  and  returns  without 
further  action.  The  Gate_Keeper  is  the  ring-crossing 
mechanism  of  the  Archival  Storage  System. 

3 .  Gate  Keeper  Module 

The  Gate_Keeper  Module  (shown  in  Appendix  A  rather 
than  as  a  figure  because  of  its  length)  consists  of 
procedures  and  primary  data  structures  and  is  the  sole 
entry  point  into  the  Kernel  from  the  Supervisor.  The 
Gate_Keeper  Module  is  written  in  PL2/ASM  since  it  is  a 
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trap  handler.  (The  user  registers  must  he  saved  when  the 
handler  is  invoked  which  reauires  access  to  the  hardware.) 
When  the  Supervisor  wishes  to  invoke  the  Kernel  it  must 
put  the  argument  list  and  space  for  any  return  message  in 
a  segment  with  read/write  access  in  the  Supervisor  ring. 
When  the  system  call  is  made,  the  pointer  to  the  arguments 
is  reauired  to  he  in  a  double  register.  The  system  call 
instruction  is  then  executed,  with  the  function-code  for 
the  reauested  Kernel  procedure  as  a  parameter  within  the 
instruction.  This  causes  the  machine  to  save  the  program 
counter,  flags  and  control  word,  and  the  instruction 
itself  on  the  system  (kernel)  stack.  An  unconditional  jump 
(hardware  initiated)  is  then  made  to  the  Program  Status 
Area  (a  vector  table)  (figure  4)  where  the  machine  state 
for  the  system  call  instruction  is  fetched.  The  Program 
Status  Area  is  established  at  system  generation  and 
consists  of  ‘frames’’  which  contain  the  machine  state  and 
location  of  the  interrupt  and  trap  handlers.  The  processor 
then  begins  execution  in  the  Kernel  ring. 

The  Sate_Keeper  first  saves  the  user  processor 
registers  and  retrieves  the  pointer  to  the  argument  list. 
If  the  argument  list  is  located  in  a  read/write  segment  of 
the  calling  rSupervi sor )  ring,  a  copy  of  the  argument  list 
is  put  onto  the  system  stack.  However,  if  the  area 
Indicated  by  the  calling  ring  is  not  in  the  read/write 
address  space  of  the  process,  the  Gate_Keeper  will  not 
return  an  error  code.  (There  is  no  place  to  return  it!) 


The  Sate_Keeper  restores  the  user  environment  and  makes  a 
normal  return. 


The  Gate_Keeper  uses  a  table  (figure  5)  to  check 
the  range  of  the  function  code.  If  the  Gate_Keeper  now 
discovers  an  error  during  the  validation  process,  it  sets 
the  return  message  to  an  error  code,  copies  the  argument 
list  hack  to  the  user  area,  and  returns  in  the  usual  way. 
If  the  call  is  valid,  the  date_Keeper  calls  the 
appropriate  module  (e.g.,  Segment  Jdanager )  at  the 
requested  entry  point  into  the  module. 

When  the  module  has  completed  the  requested  task 
it  returns  to  the  date_Keeper .  The  return  message  is  then 
copied  to  the  user's  return  argument,  and  a  return  to  the 
user  ring  occurs.  All  entries  into  and  exits  from  the 
Kernel  are  through  the  da te_Keeper . 

Parameter  passing  to  and  from  the  Kernel  is  by 
value  only.  Since  implementation  details  of  how  . ?LZ 
modules  pass  parameters  are  unknown,  the  decision  on  the 
precise  mechanism  for  arsument  passing  is  left  for  the 
implementor.  It  may  be  best  to  align  the  method  of 
parameter  passing  as  closely  as  possible  to  the  method 
used  by  the  PL2/STS  language. 

4 .  Segment  Manager  Module 

The  Segment_Man agar  is  responsible  for  managing 
the  segmented  physical  memory  and  uses  the 
Known_Segment_Table  CKST)  as  its  primary  database.  In 
keeping  with  the  ’ ^op-free  structure  and  since  the 
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Figure  5.  Parameter  Table 


25 


Segment_Manager  is  the  only  module  at  level  3  of  the 
Kernel,  only  calls  external  to  the  Kernel  domain  may  he 
made  to  the  Segment_Manager .  There  are  six  entries  into 
the  Segment  Jlanager  in  this  implementation: 

1)  Create_Segmer.t 

2)  Delete_Segment 

3)  l*ake_Knovn 

4)  Terminate 

5)  Swap_In 

6)  Swap_0ut 

a.  Known  Segment  Table 

The  data  structure  used  by  the  Segment_Manager 
to  manage  segments  is  the  Known  Segment  Table  (KST).  The 
KST  is  a  ’’process  local"  data  structure  and  contains  an 
entry  for  each  segment  which  the  process  has  declared  an 
intention  to  use  (viz.,  "made-known").  The  segments  may  or 
may  not  be  located  in  main  memory.  If  a  segment  has  an 
entry  in  the  KST,  then  the  segment  is  described  as  known 
to  the  process.  In  this  design  it  will  also  have  an  entry 
in  the  Active  Segment  Table  (AST — -a  Memory_Manager 

database  explained  later)  and  can  be  described  as  active. 
The  KST  (figure  5)  is  indexed  by  the  segment  numbers 

(Segment _4)  which  are  assigned  by  the  Segmen t Manager  .  The 
Segment_#  also  corresponds  to  the  MMU  descriptor  register 
for  the  segment.  The  AS  TK_#  is  the  Active  Segment  Table 
entry  number  and  is  obtained  from  the  Pemo ry_Manager .  The 
ASTI_#  is  the  "handle"  which  is  passed  to  the 


Memory_Manager  when  necessary  to  identify  a  particular 
active  segment.  The  Size  field  is  an  integer  which  is  the 
size  of  the  segment  in  bytes  divided  hy  256.  All  segments 
are  created  in  multiples  of  256  bytes  because  of  MMU 
constraints.  An  upper  bound  ( Max_Segmen t_5 i ze )  is  placed 
on  the  segment  Size  by  the  design  (explained  later).  A 
flag  known  as  In_Core  is  used  to  indicate  whether  the 
segment  is  in  main'  memory  or  on  secondary  storage. 

The  last  field  in  the  KST  entry  is  the  access 
class  of  the  segment.  This  is  a  label  which  indicates  the 
security  classification  of  the  segment.  Interpretation  of 
the  Class  to  determine  an  access  mode  (read  or  read/write) 
is  performed  by  the  software  (by  a  call  to 
Non_Discretionary_Security )  on  first  reference;  thereafter 
the  access  mode  is  enforced  by  the  MMU. 

Figure  6  shows  both  the  logical  view  and  the 
PLZ  variable  declaration  for  the  1ST.  Max_KST_Size  is 
hardware  dependent  and  is  equal  to  the  maximum  number  of 
segments  which  can  be  mapped  by  the  mM(J.  To  access  an 
element  of  the  database  the  following  notation  is  used: 

KST  [Segment-#! .  ASTE_# 

If  Segments  is  equal  to  103  then  the  above  statement  will 
reference  the  ASTI_#  field  of  the  KST  entry  for  segment 
number  103. 

b.  Creation  and  Deletion  of  Segments 

Create_Segment  and  Delete_Segment  are  two  of 
the  six  Supervisor  entries  into  the  Segment_Manager . 
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r-  Segment_# 


Hfl 

Access 

Mode 

mm 

Class 

Known  Segment  Table  Logical  View 


Type 

KST_Entry  Record  [ASTE_#  AST  Index 

Size  Integer 
Access_Moae  Integer 
In_Core  Byte 
Class  Lonsword] 

Internal  !  Internal  to  the  Segment  Manager  ! 
KST  Array  [Max_KST_S i ze  KST_Entry] 


Known  Segment  Table  Database  Definition 


Figure  6.  Known  Segment  Table 
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Create_Segment  (figure  7)  is  the  function  which  adds  a  new 
segment  to  the  Archival  Storage  System  after  validating 
the  parameters  which  are  passed.  The  creation  of  a  segment 
is  accomplished  by  requesting  the  Memory_Manager  process 
to  make  an  entry  in  the  Alias  Table  and  to  allocate 
storage  on  secondary  media. 

The  Alias  Table  is  a  database  which  is 
maintained  by  the  Memory_Manager .  It  is  a  result  of  the 
aliasing  scheme  used  by  the  Kernel  to  prevent  passing 
systemwide  information  (such  as  the  unique  identification 
of  a  segment)  out  of  the  Kernel  [20].  The  alias  of  a 
segment  is  the  segment  number  of  a  ’’mentor’’  segment  (a 
process  local  variable)  and  the  entry  number  in  the 
Alias_Table.  The  princinal  implication  of  the  aliasing 
scheme  is  that  a  mentor  segment  must  be  Known  before  a 
segment  can  be  created.  The  Alias  Table  will  be  further 
explained  in  a  succeeding  section. 

The  arguments  which  must  be  passed  to 
Create_Segment  are  the  Men tcr_Segment_rf f  the  desired 
2ntry_#  (in  the  Alia s_Table )  ,  the  Class  of  the  segment  (a 
label),  and  the  desired  Size  of  the  segment.  The  KST  is 
searched  to  insure  that  the  Mentor  segment  is  known.  Mext, 
'Jon_Discretionary_Security  must  be  called  to  determine  if 
the  segment  is  comoatible  [2],  !To  be  compatible,  a  mentor 
segment  classification  must  be  less  than  or  equal  to  the 
created  segment.)  The  compatibility  checK  can  be  performed 
in  the  Segment_Manager  or  the  Me.mory_Manager .  In  addition 
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Create_Segment  Procedure  (Mentor_Segment_#  Integer 

Entry_#  Integer 
Class  Longvord 
Size  Integer) 

Returns  (Success_Code  Integer) 

Entry 

Do 

If  1ST [Ment or_Segmen t_#] . ASTE_#  =  Null 
Then  Success_Code  :=  Mentor_Seg_Not_Found 
Exit 
Ei 

If  Non_Disc_Security(?rocess_Class, 

EST [Ment or_Segment_#] .Class )  O  Equal 
Then  5uccess_Code  :=  Not_Alloved 
Eli  t 
Fi 

Compa  t_Checlc  :=  Non_Disc_Security( Class  , 

EST [Mentor_Segment_#] .Class ) 

If  Compa t_Checs  =  Less_Than 
Orif  Compa  t_Checlr  =  Not_Related 
Then  Success_Code  :=  No t_Compatible 
Exit 
Fi 

If  Size  >  Max_Segment_Size 
Then  Success  Code  :=  Segment  Too  Large 
Exit 
Fi 

Signal  ( Memory_Manager  ,  Create  Entry, 

EST  [Mentor_Segment_#T.ASTE_*,Entry_#,Class .Size ) 
Success  Code  :=  Wait 


End  C rea te_Segment 


Figure  7.  Create_Segment  Procedure 
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to  the  compatibility  check,  a  check  must  be  made  to 
determine  if  the  process  access  class  is  equal  to  the 
access  class  of  the  Alias_Table  since  adding  an  entry 
implies  write  permission  to  the  Alias_Table.  A  check  is 
then  made  on  the  Size  parameter  to  insure  that  it  is  in 
the  range  of  256  bytes  to  32K  bytes.  The  maximum  size  of  a 
segment  is  determined  by  the  size  of  the  design  of  the 
secondary  storage  page  table  and  the  hardware  constrains 
the  segment  to  multiples  of  256. 

If  an  error  is  discovered  during  any  of  the 
preceding  checks,  then  an  appropriate  error  code  is 
returned  (e.g.,  Parent_Segment_Mot_Found ) .  If  tnere  are  no 
errors,  the  Segment_Manager  Signals  the  Memory_Manager 
with  a  request  to  make  an  entry  in  the  Alias_Table.  The 
Segment_Manager  must  Wait  for  a  success  code  from  tne 
Memory_Manager  since  the  Entry_*  can  only  be  checked  for  a 
duplication  by  the  Memo ry_Manager .  When  the  Memory_Manager 
Signals  the  Sesment_Manager  that  the  task  has  been 
completed,  the  Segment_Manager  returns  the  Success_Code  to 
the  process.  Note  that  the  segment  has  only  been  created 
and  if  the  Supervisor  now  wishes  to  reference  the  segment 
it  must  first  request  the  seement  be  entered  into  the  KST 
(Make_Xnown) . 

Delete_Segmen t  (figure  8)  accomplishes  the 
reverse  of  Create_Seg'”ent ,  that  is  the  removal  of  a 
directory  entry.  The  two  input  parameters  for 
Delete_Segment  are  Mentor_Segment_*  and  Tntry_*.  Again, 
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Delete_Segment  Procedure  ( Mentor_Segment_#  Integer 

Entry_#  Integer) 

Returns  (Success_Code  Integer) 

Entry- 

Do 

If  KST[Mentor_Segment_#] . ASTE_*  =  Null 
Then  Success_Code  :=  Mentor  Seg  Not  Found 
Ex  i  t 
Fi 

If  Non_Dlsc_Securlt y( Pr oc es s_ Cl as s , 

KST [Ment or_Segment_#] . Class )  =  Equal 
Then  Signal  (Memory_Manager,Delete_Entry, 

EST  [Mentor_5egment_#]  . ASTE_# , Entry 
Success_Code  :=  Wait 
Else  Success_Code  :=  Not  Allowed 
Fi 
Od 

End  Delete_Segment 


Figure  3.  Delete_Segent  Procedure 


the  mentor  segment  must  be  known  before  the 

Segment_Manager  can  honor  the  request.  Since  the  mentor 
segment  must  be  known,  compatibility  was  checked  when  the 
segment  was  created.  The  process  access  class  must  also  be 
equal  to  the  access  class  of  the  mentor  segment  since 
deleting  an  entry  implies  write  permission.  When  all 
security  checks  have  been  made,  the  3egment_Manager 
Signals  the  Memory_Manager  to  delete  the  entry  from  the 
Alias_Table.  The  Seament_Manager  Waits  for  the 
Memory_Manage r  to  complete  the  task  and  it  returns  the 
Success_Code  from  the  Memory_Manager  to  the  Supervisor 
process.  The  Wait  is  necessary  because  an  error  occurs  if 
the  Mer.tor_Seement  is  not  empty  prior  to  the  deletion, 
c.  Managing  the  Segmented  Address  Space 

A  process  must  declare  an  intention  to  use  a 
segment  before  it  can  reference  the  segment.  This 
declaration  introduces  the  segment  into  the  address  space 
of  the  process.  The  way  the  Supervisor  declares  its 
intention  to  use  a  segment  is  to  ask  that  a  Segment_#  be 
assigned.  This  results  in  an  entry  in  the 
Known_Segmen t_Table .  Make_£nowr.  is  the  entry  point  into 
the  S egment _Manager  to  accomplish  an  entry  in  the  1ST. 

A  call  to  Make_Inowr.  (figure  9)  requires  three 
parameters:  1)  Ment or_S egment_* ,  2)  3ntry_*,  and  3) 

Acces  s_Mode_Des  i  red .  Segmer.t_#  is  the  value  which  the 
Segment_Maaager  returns  to  the  Supervisor  process  and  is 
the  index  to  the  KST  entry  and  to  the  sesment  descriptor 
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Mal£e_Knova  Procedure  ( Mentor_Segment_#  Integer 

Entry_#~Integer 

Access_Mode_Desi red  Access_Mode) 

Returns  (Segment_#  Integer 

Access_Mode_Alloved  Access_Mode 
Success_Code  Integer) 

Local  Index  Integer 
ASTE_#  Word 
Class  Longword 
Size  Integer 

Entry 

Get_Seg_#:  Do 

If  EST  [Mentor  Segmen t_#]  .ASTS#  =  Mull 
Then  Success_Code  :=  Mentor_Not_Known 
Exit  From  Get_Seg_# 

Else  Signal  ( Memory_Manager .Activate , 

KST  [Mento r_Segment_#] . ASTE_# ,Entry_* ) 

ASTE_#,  Class,  Size,  Succiss_Code  :=  Wait 
If  Success_Code  =  Segment_Found 
Then  Index  :=  0 
Search:  Do 

If  KST  [Index] .ASTE_#  =  ASTE_# 

Then  Segment_*  :=  Index 

Success_Code  :=  Already_Knovn 
Access  Mode_Allowed  := 

K^T  [Segmen t_#] .Access_Mode 
Exit  From  Get  See_# 

Fi 

Index  +=  1 

If  Index  >  Max_Number_Of_Segments 
Then  Exit  From  Search 
Ft 

Repeat  From  Search 
Cd  ISearch! 


Figure  9.  Make_Knovn  Procedure 
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Index  :=  0 
Find  Entry:  Do 

If  KST  [Index] .ASTE_#  =  Null 
Then  If  Non_Disc,Security( ?rocess_Class , 
Class!  =  Less_Than 

Orif  Non_Disc_Security (Process_Class , 
Class)  =  Not_?.elated 
Then  Access_Mode, Allowed  :=  Null 
Else  If  Non^Disc^Security (Process_Class , 
Class)~=  Equal 
Then  Access_Mode_Allowed  := 
Acc?ss_Mode,Desired 
Else  Access  Rode, Allowed  :=  Read 
Fi 
?i 

If  Access_Mode_Allowed  <>  Null 
Then  Segment_#~:=  Index 

KST [Segment,#] .ASTE,#  :=  ASTE  # 

KST  [Segment^#*]  •  Class  :=  Class 
KST [Segment,#] . Access_Mode  := 
Access, Modi, All  owed 
KST  [Segmen t_#]  . Si ze  :=  Size 
KST  [Segment,#] . In_Core  :=  No 
Success  Code  :=  Segment_?ound 
Inner,TC (' Add  _S  eg,  Segmen  t  _# , 

Acce ss, Mo de_Al lowed ) 

Else  Segment,#  :=  Null 

Success  Code  :=  Not_Allowed 
Fi 

Exit  From  Find_Entry 
Fi 

Index  +=  1 

If  Index  >  Max_Number_Of, Segments 
Then  Segment,#  :=  No_Segments_Avai 1 
Exit  From  Get  Seg  # 

Fi 

Repeat  From  Find_Sntry 
Od  !Find,EntryI 
Od  !Get_Seg,#! 

End  Ma<ce  Known 


Figure  9.  Make_Known  Procedure  (Continued) 
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in  the  MMU  hardware.  Different  processes  using  the  same 
segment  will  not  have  the  same  Segment_#  for  the  segment, 
since  each  process  has  its  own  K5T.  Three  parameters  are 
returned  from  Make_Known:  1)  the  assigned  Segment_*,  2) 
the  Access_Mode_Allowed  which  may  he  less  than 
Acces s_Mode_Reaues  ted ,  and  3)  a  Success_Code.  If  the 
Success_Code  indicates  an  error  the  first  two  parameters 
are  Null. 

Make_Known  first  Signals  the  Memory_Manager 
and  Waits  for  the  ASTE_»  of  the  segment.  If  more  than  two 
rings  were  implemented,  ring  brackets  would  also  oe 
reouired  from  the  Me^ory_Manager  [*13]  .  A  search  of  the  KST 
then  will  reveal  if  the  segment  is  already  known.  If  it  is 
known,  the  assigned  Segment_*  the  Access_Mode_Allowed 
(unchanged),  and  a  Success_Code  of  Already_Known  are 
returned.  Acces s_Mode_Al lowed  cannot  he  changed  for 
segments  in  the  address  space.  If  there  is  no  entry  in  the 
KST ,  an  entry  is  made  hy  filling  m  the  columns  of  the  KST 
at  the  first  available  Segment_#. 
Non_Discretionary_Security  is  called  to  interpret  the 
security  labels  of  the  subject  and  the  object.  Access  to 
the  segment  is  then  granted  with  the  access  allowed  equal 
to  the  less  privileged  of  Access_I“!ode_Desired  or 
Max_Acce ss_All owahle .  If  write  access  is  requested  hut 
security  allows  only  read,  read  is  the  access  granted.  A 
call  must  also  he  made  to  the  Inner_Traffic_Controller  to 
add  the  segment  descriptor  to  the  hardware  descriptor  list 


(MMU)  and  the  software  image  of  the  descriptor  list. 

If  the  maximum  number  of  segments  is  exceeded 
Make_Inovn  will  return  No_Segment_Available.  The  process 
then  has  the  option  of  terminating  any  other  segment  to 
make  room  for  the  required  segment.  (Note  that  the  maximum 
number  of  segments  allowed  by  the  hardware  could  be 
exceeded  without  using  ail  of  the  linear  "virtual  core" 
allocation  or  conversely.)  Terminate  is  the  entry  point  in 
the  Segment _Mar.ager  to  remove  a  segment  from  the  531. 

Terminate  (figure  13)  is  responsible  for 
removing  the  segment  from  the  address  space  and  reflects 
this  by  removing  the  entry  from  the  55T .  The  only  argument 
which  must  be  passed  is  the  Segment_*  to  be  terminated. 
The  return  argument  is  a  Success_Code .  There  are  four 
errors  which  can  be  found  by  the  Segment_Manager :  1)  a 
segment  which  is  not  known,  2)  attempting  to  terminate  a 
segment  still  loaded  in  the  process  virtual  core,  3) 
attempting  to  terminate  a  Kernel  segment,  and  4)  passing 
an  invalid  Segment_=*  (too  large).  The  Memory_Manager  is 
Signaled  to  Deactivate  the  segment  (remove  the  AST  entry) 
and  a  Wait  occurs  until  the  Deactivate  is  completed.  Note 
that  the  Wait  is  to  insure  that  a  race  condition  between 
the  Memo ry_Ma eager  and  Supervisor  process  [11]  does  not 
occur.  The  1ST  entry  is  deleted  by  setting  the  AST_*  of 
the  1ST  entry  to  null,  calling  the 
Inaer_Traf f ic_Controller  to  delete  the  segment  from  the 
descriptor  segment  and  returning. 
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Terminate  Procedure  (Segment-#  Integer) 

Returns  (Success_Code  Integer) 

Entry 

Do 

If  KST[Segment_#] .ASTS_#  =  Null 
Then  Success  Code  :=  Segment_Not  Known 
Exit 
Fi 

If  KST [Segment-#]  .In_Core  =  Tes 
Then  Success_Code  :=  Segment_In_Core 
Sxi  t 
Ei 

If  Segment-#  <=  Numher_Kernel_Segments 
Then  Success  Code  :=  Kernel  Segment 
Sxi  t 
Fi 

If  Segment-#  >  Max_Segment_# 

Then  Success_Code  7=  Invalid-Segment-# 

Exi  t 
Fi 

Signal  ( Memor7_Manager  .Deactivate  ,KST  [Segment-#]  .AST 

Success_Code  :=  Wait 

KST [Segment-#] .ASTS_#  :=  Null 

Inner_TC (Eelete_Seg  .Segment-#) 


End  Terminate 


Figure  10.  Terminate  Procedure 


d.  Moving  Segments  into  Memory 

Swa?_In  (figure  11)  and  Swap_Cut  (figure  12) 
are  the  two  procedures  in  the  Segment_Manager  which  move 
segments  between  main  memory  and  secondary  storage. 
(Secondary  storage  is  used  as  a  generic  term  in  this 
thesis  to  indicate  all  memory  of  a  computer  system  other 
than  main  or  core  memory.  It  includes  ’’tertiary'’  or  lower 
order  memory.)  To  move  a  segment  from  secondary  storage  to 
main  memory,  a  process  must  call  Svap_In  with  the 
Segment_#  and  3ase_Address  as  arguments.  3ase_Address  is 
the  location  in  the  linear  virtual  core  of  the  process 
where  the  segment  is  to  begin.  This  is  a  virtual  core 
address  and  does  not  correspond  to  a  real  address  in 
memory?  in  fact,  memory  cannot  he  addressed  at  all  except 
by  addressing  a  segment.  The  Segment_Manager  indexes  to 
the  segment  in  the  KST  to  retrieve  the  necessary 
attributes  for  moving  the  segment.  If  the  segment  is  not 
found,  Segment_Nct_?ound  is  returned.  After  obtaining  the 
attributes  of  the  segment,  the  Segmen t Manager  Signals  the 
Memory_Manager  to  do  the  transfer.  A  Wait  is  then  executed 
until  the  Memory_Manager  can  send  the  Abso lute_Address  in 
real  memory  to  the  Segment_Manager .  This  information  is 
passed  to  the  Inner_Tra? f ic_Controller  to  update  the 
absolute  address  in  the  hardware  and  software  descriptor 
lists.  This  procedure  only  works  because  of  the  design 
choice  not  to  unload  a  process  from  a  virtual  processor. 
If  processes  are  unloaded  the  Memcry_Manager  would  have  to 
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Svap_In  Procedure  (Segment-#  Integer 

3ase_Address  Word) 

Returns  ( Success_Code  Integer) 

Entry 

If  KST[Segment_#]  .ASTS_#  =  Null 
Then  Success_Code  :=  Seg_Not_Found 
Exit 
Fi 

Signal  ( Memory_Manager ,  In, Segment-#, 

IS T  [Segment_*] . ASTE_#, 3ase_Address , 

1ST [Segment-#] >Access_Mode ) 

Absolute_Ad dress , Sue  cess _Code~ :=  Wait 
If  Success_Code  =  Swapped_In 

Then  Inner_TC  ( Load , Segment  # ,Absolute_Address  , 
KST [Segment_*T . Si ze ) 

IST[Segment  #].In_Core  :=  Tes 
Fi 

End  Swap-In 


Figure  11.  Swap-In  Procedure 


Swap_Out  Procedure  (Segment_<*  Integer) 

Returns  ( Succe ss_Code  Integer) 

Entry 

If  KST [Segmen t_#l .ASTE_#  =  Null 
Then  Success_Code  :=  Sig  Not  Pound 
Ex  i  t 
Pi 

Written  :=  Inner_TC  (Unload, Segment_#) 

Signal  (l^emory_Manager  ,0ut  ,EST  [Segment_i*1  .ASTE 
KST  [Segment..*] .In_Core  :=  No 
Success_Code  :=  Svapped_Out 

End  Swap_0ut 


Pigure  12.  Swap_0ut  Procedure 
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call  the  Inner_Traff lc_Controller.  The  parameter  returned 
to  the  process  indicates  if  the  segment  swap-in  was 
successful . 

The  move  in  the  other  direction — mam  memory 
to  secondary  storage — is  performed  hy  Swap_0ut.  The  only 
input  argument  is  the  Segment_#  and  Success_Code  is  the 
only  return  argument.  After  validation  of  the  Segment_#, 
the  Segment_Manager  calls  the  Inner_Traf f ic_Controller  to 
obtain  the  status  of  the  hardware  changed  bit.  This  is  in 
turn  passed  by  Signal  to  the  Memory_Manager  to  make  the 
change.  Success_Code  is  set  to  Swap_Qut  and  the 
Segment_Manager  returns.  If  more  than  one  processor  is 
used  in  the  system,  race  conditions  should  be  investigated 
in  this  procedure  of  allowing  the  Segment_!“tanager  rather 
than  the  l“'emory_Ma  nager  to  call  the 
I nner_Traffic_Cont roller. 

To  this  point  the  usual  order  for  invoicing  the 
Segment_Manager  functions  has  not  been  specified.  There  is 
a  usual  seauer.ce  of  events.  In  order:  Create_Segmer.t  to 
make  an  Alias_Table  entry,  ihake_£nown  to  introduce  the 
segment  into  the  address  space,  and  Swap_In  to  move  the 
segment  into  the  process's  virtual  core  are  the  steps 
necessary  before  a  process  can  make  a  reference  to  a 
segment.  Conversely,  Swap_0ut,  Terminate,  and 
Delete_Segment  is  the  order  to  move  a  segment  from  main 
memory  to  secondary  storage,  remove  the  entry  from  the  KST 
and  descriptor  from  the  PPU,  and  remove  the  segment  from 
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the  address  space.  If  the  functions  are  called  in  any 
other  order,  the  usual  result  is  an  error  condition  and  no 
action  is  taken.  No  ‘ham’  results  from  calls  made  out  of 
sequence . 

5 .  Traffic  Controller  Module 

The  Traf f ic_Controller  is  responsible  for 
multiplexing  processes  onto  virtual  processors.  A  virtual 
processor  is  an  abstraction  which  describes  a  logical 
processor.  There  are  multiple  virtual  processors  which 
exist  on  a  single  physical  processor.  The 
Traf f ic_Controller  is  also  the  Kernel  module  which 
supports  the  interprocess  communication  primitives,  Block 
and  Wake_'Jp.  In  the  Archival  Storage  System,  Block  and 
«ake_Up  are  the  last  two  of  the  sii  user  entries  into  the 
Kernel.  There  are  four  other  procedures  in  the 
Traf f ic_Con troller  which  implement  the  scheduling 
algorithm  and  provide  message  aueue  services  for  Block  and 
Wake_Up. 

a.  Active  Process  Table 

The  database  of  the  Traf f ic_Ccntroller  is  the 
Active  Process  Table  (APT)  (figure  13).  This  is  a 
fixed-size  table  in  the  Kernel  because  of  the  decision  not 
to  create  or  destroy  processes.  When  the  Archival  Storage 
System  goes  through  system  generation,  each  process  will 
be  created  and  an  entry  made  in  the  APT.  The  process  will 
then  be  active  for  the  life  of  the  system.  Each  active 
process  will  have  a  uniaue  identifier  (?rocess_ID)  which 
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is  also  the  index  to  the  APT.  Note  that  if  processes  were 
created  and  destroyed,  then  allowing  ?rocess_IDs  to  leave 
the  Kernel  could  create  a  communication  path.  In  that  case 
the  Process_ID  should  he  ’virtualized".  The  State  field  of 
the  APT  indicates  whether  a  process  is  blocked,  ready,  or 
running. 

An  explanation  of  the  interprocess 
communication  primitives  is  necessary  here.  Block  and 
Wake_Up  [19]  are  the  interprocess  communication  primitives 
used  by  cooperating  processes  in  the  Supervisor  domain. 
Invocation  of  the  primitives  is  actually  a  call  to  the 
Traffic_Controller  and  causes  the  Traff ic_Con troller  to 
execute  the  scheduling  algorithm.  A  process  calls  Wake_vJp 
when  it  has  a  message  or  task  for  another  process.  Wake_Up 
will  set  the  state  of  a  blocked  process  to  ready.  If  the 
process  Is  ready  or  running  it  will  have  no  effect  on  the 
status  of  the  process.  When  a  process  cannot  continue 
execution  until  a  reply  to  a  ¥ake_Up  is  received,  the 
process  must  block  itself.  31ock  will  set  the  process 
status  to  blocked. 

Within  the  Kernel  Signal  and  Wait  are  the 
primitives  used  for  communication.  They  function  in  the 
same  manner  as  Block  and  Wake_up,  but  are  calls  to  the 
Inner_Traf f ic_Controller  instead  of  the 
Traff ic_Controller .  Signal  and  Wait  are  bounded  in  time 
which  indicates  that  they  are  guaranteed  to  return.  Block 
and  Wake_Up  are  not  bounded  since  no  claims  can  be  made 
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about  correctness  of  calls  from  outside  the  lernel.  It  is 
possible  for  a  user  process  to  call  31ock  erroneously  and 
never  be  heard  from  again. 

The  Wake-Up  Waiting  Switch  is  Saltzer's  [19] 
mechanism  for  synchronization  of  interprocess 
communication  primitives.  Without  the  switch  a  race 
condition  can  occur.  For  example,  the  following  sequence 
of  events  could  happen  because  processes  can  run 
simul taneously : 

1)  Process  A  looks  in  its  work  queue 
and  finds  it  empty. 

2)  Process  3  puts  a  task  in  A's  work  queue. 

3)  3  wakes  up  A. 

4)  A  blocks  itself. 

At  step  3,  A  was  running,  so  the  wake-up  sent  by  3  was 
ignored.  When  A  called  block,  a  task  is  in  the  work  queue, 
but  A  missed  the  wake-up  signal,  so  the  task  remains 
uncompleted.  In  particular,  if  A  was  expecting  some  event 
necessary  for  A  to  continue,  A  may  never  wake-up. 

The  Wake-Up  Waiting  Switch  prevents  the 
occurrence  of  such  a  situation  by  requiring  the  following 
sequence  of  actions: 

Process  3: 

1)  Process  3  puts  task  in  Process  A's 
work  aueue. 

2)  Wake-up  A  and  turn  wake-up  waiting 


switch  on. 


Process  A: 

1)  Reset  the  wake-up  waiting  switch  to  off. 

2)  Look  in  the  work  queue  and  find  it  empty. 

3)  Call  Block,  which  returns  if  wake-up 
waiting  switch  is  on. 

Mow,  the  above  sequences  can  occur  in  any  time 
relationship  and  the  wake-up  signal  will  have  the  desired 
effect . 

The  Traf f ic_C ontroller  uses  the  priority  field 
for  determining  what  process  to  schedule  to  run  on  the 
virtual  processor.  The  Heouired_7irtual_?rocessor  field  is 
used  to  hind  a  loaded  process  to  a  specific  virtual 
processor.  Only  two  processes  run  on  a  virtual 
processor — the  loaded  process  and  the  "idle"  process.  This 
is  a  direct  result  of  the  simplifying  design  choice  (to 
have  all  processes  loaded)  made  for  the  Archival  Storage 
System.  In  general,  processes  must  be  loaded  and  unloaded. 
The  Idle  process  is  put  into  the  running  state  whenever 
the  loaded  process  blocks  itself. 

b.  Interprocess  Communication  Primitives 

Because  the  Archival  Storage  System  does  not 
allow  creation  or  destruction  of  processes  except  at 
system  generation,  the  only  external  entry  points  into  the 
Traf fic_Con tro Her  are  Block  and  i*ake_Up.  As  previously 
explained,  Elock  and  '#'ase_Up  are  the  primitives  used  by 
Supervisor  processes  for  interprocess  communication. 

Block  (fisure  14)  is  called  when  a  process 


Block  Procedure 

Returns  (Process_ID  Integer 

Message  Mes sage_Type ) 

Entry 

If  APT  [Process_ID] .Wakeup_Wai ting_Switch  =  On 
Then  APT  [Proceis  ID] .Wakeup_Wai t ing_S*i tch  :=  Off 
Else  APT  [?rccess~IBJ  .Sta te  :=  Blocked 
Sched  Read7_?rocess 

Fi 

?rocess_ID .Message  :*  Get_Firs t_Mes sage( Message_Queue ) 
End  31ock 


Figure  14.  Block  Procedure 


cannot  continue  until  the  occurrence  of  some  other  event. 
After  going  through  the  Qate_Keeper ,  the  call  enters  the 
Traff ic_Controller.  The  Wake_Up_Waiting_Switch  is 
immediately  checked.  If  the  switch  is  on,  the  switch  is 
reset  to  off,  and  the  first  message  in  the  Message_Cueue 
for  the  process  is  retrieved.  The  Traff ic_Controller  then 
returns  through  the  Gate_Keeper . 

If  the  Wake_tJp_Wa i ting_Swi t ch  was  off  then  the 
state  of  the  process  is  set  to  31ocked. 
Sched_Ready_Process  is  called  to  schedule  the  highest 
priority  ready  process  on  the  virtual  processor.  In  the 
Archival  Storage  System  this  is  a  trivial  task,  because 
the  only  other  process  which  is  loaded  on  the  virtual 
processor  is  the  idle  process.  The  idle  process  can  never 
block  itself,  so  it  must  always  be  either  running  or 
ready.  In  fact  the  idle  process  will  only  consist  of  a 
halt  instruction. 

The  Traff ic_Controller  could  have  been 
collapsed  into  the  Inner_Traf fic_C ontroller  for  this 
design,  but  preservation  of  generality  was  a  design  goal. 
Later  extensions  will  be  easier  to  implement  since  the 
basic  structure  of  the  Traf fic_Controller  is  present. 

The  counterpart  of  Block  is  Wake_Uo.  *ake_Up 
(figure  15)  is  used  by  processes  in  the  Supervisor  domain 
to  pass  messages  to  other  processes  in  the  Supervisor 
domain.  Upon  entry  into  Wake_Up,  the  message  is  placed  in 
the  Message  Queue  of  the  awakened  process.  The 
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Wake_Up  Procedure  (Wakeup_Proces s_ID  Integer 

Message  Message^Type ) 

Returns  (Success_Code  Integer) 

Entry 

Do 

Success_Code  :=  Inser t_Message ( Wakeup_?rocess_ID  Message) 
If  Success_Code  =  Queue_0 verf low 
Orif  Success_Code  =  Not_Allowed 
Then  Exit 

Else  APT  [Wakeup_?rocess_ID] .Wakeup_Waiting_Switch  :=  On 
If  APT  [Wakeup_Process_ID]  .S tate  =  31ocked 
Then  APT  [Wakeup_Process_ID] .State  :=  Ready 
Enter  Ready  Queue  (Wakeup  Process  ID) 

FI 

APT  [Process_ID]  .State  =  Ready 
Enter_Ready_Q.ueue  (Process_ID ) 

Sched_Ready_P  roc ess 

FI 

Od 

End  Wake_Up 


Figure  15.  Wake-up  Procedure 
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Wake_Up_Waitins_Switch  of  the  process  to  he  awakened  is 
then  set  to  On.  Then  if  the  process  state  is  blocked  it  is 
put  into  the  Ready_Cueue  and  the  State  is  set  to  ready. 
Regardless  of  the  state  of  the  awakened  process,  the 
waking  process  then  puts  itself  into  a  Ready  State  and 
Inters  the  Ready_Queue  itself.  This  is  necessary  because 
the  process  to  be  awakened  may  ha7e  a  higher  priority  than 
the  waking  process.  Ivery  time  either  Block  or  Wake_Up  is 
called  the  scheduling  algorithm  is  executed 
(5ched_Ready_?rocess ) . 

c.  Process  Scheduling  Algorithm 

Inter_P.eady_Oueue  (figure  16)  and 
Sched_Ready_?r ocess  (figure  17)  are  two  internal  functions 
of  the  Traf fic_Controller .  In ter_5eady_9ueue  is  used  for 
placing  a  ready  process  into  a  first-in,  first-out  queue 
which  is  organized  by  priority  (figure  IS).  The 
Ready_Queue  is  designed  as  a  two-dimensional  array  indexed 
by  Priority  and  a  top  and  bottom  pointer.  The  alsorithms 
for  all  queue  operations  are  ta.cen  from  Inuth  [21].  When  a 
?rocess_ID  is  to  be  added  to  the  queue  the  bottom  pointer 
for  the  appropriate  priority  queue  is  incremented  by  one. 
If  the  bottom  pointer  is  at  the  bottom  of  the  linear  array 
which  implements  the  queue  then  it  is  set  to  the  first 
location  of  the  array,  thus  wrapping  around.  The  physical 
length  of  each  queue  column  is  equal  to  the  total  number 
of  processes  which  can  be  entered  into  that  queue  at  any 
pclnt  in  time  so  that  the  queue  cannot  overflow.  The 
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Entry 

If  Ready  Queue_Sottom  [APT  [?rocess_ID] .Priority]  = 
iv!ax_Queue_  Length 

Then  Ready_Queue_3ottom  [APT  [Process_ID] .Priority]  :=  0 
Else  Ready  Queue’Bottom  [APT  [Process  ID] .Priority]  +=  1 
Fi 

Peady_Queue [ APT  [Process_ID] .Priori tyf  Ready_0ueue_3ottom] 

:=  Process_ID 

End  Ente r_Ready_Queue 


Figure  16.  Ent er_Ready_Queue  Procedure 
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Scked_Ready_?r ocess  Procedure 
Entry 

Priority  :=  Max_Priority 
Scan:  Do 

If  Ready_Queue_Top  [Priority]  = 
Ready~Queue~3ott om  [Priority] 
Then  Priority  -=  1 

If  Priority  <  Min_Priority 
Then  Exit  From  Scln 
Else  Repeat  From  Scan 
Fi 


Else  If 

a 

eady_Queue_T op  [? 

riority]  = 

Max  Queue 

_Lengt. 

Th 

en 

Ready_Que ue_Top 

[Priority] 

:=  2 

El 

se 

Ready _Queue_T op 

[Priority] 

+=  1 

Fi 

Run : 

If 

APT  [Ready_?roce 

ss  ID]  .Reqd  7irt_?ro 

cessor 

=  Processor  I 

D 

Then  APT  [Ready  ?r 

ocess  ID]  . 

State  :=  Running 

Inner_TC  (Swa 

p  MMU, Ready  Process 

ID) 

El 

se  Get_Next_Proc 

ess (Ready_ 

Queue ) 

Fi 

Repeat  From  3 

un 

Fi 

Od 


End  Sched_Ready_Process 


Figure  17.  Sched_Ready_?rocess  Procedure 
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?rocess_ID  is  placed  into  the  array  at  the  location 
pointed  to  by  the  bottom  pointer.  The  queue  is  always 
entered  at  the  logical  bottom  and  removal  takes  place  from 
the  logical  top. 

The  procedure  which  removes  the  processes  from 
the  top  of  the  queue  is  Sched_Ready_Process .  The  function 
of  Sched_Ready_Process  is  to  "pass"  (as  a  baton  in  a  relay 
race)  the  current  virtual  processor  to  the  highest 

priority,  ready  process  which  can  run  on  this  specific 
virtual  processor.  Starting  with  the  Max_Priority  queue, 
each  queue  is  scanned  until  the  first  ready  process  that 
can  run  on  the  virtual  processor  currently  executing  in 
the  Tra ffi c_C on t roller  is  encountered.  Each  oueue  is 
tested  in  turn  to  determine  if  it  is  empty.  If  the  queue 
is  empty,  then  the  next  lower  priority  queue  is  scanned. 
The  existence  of  an  Idle  process  for  each  virtual 

processor  guarantees  that  a  ready  process  is  always  found, 
so  the  Traf f ic_Controller  cannot  exit  without  scheduling  a 
process.  When  a  ready  process  is  found,  then  the  process 
State  is  set  to  running  (scheduled)  and  the 

Inner_Traf f ic_Controller  is  called  to  SwapJtMU.  This 
generally  will  load  the  process  descriptor  segments  into 
the  Virtual_?rocessor_MMU,  but  in  the  design  of  the 
Archival  Storage  System  the  MPU  of  the  Idle  process  is 
identical  to  the  h!MU  of  the  loaded  process, 
d.  Message  Cueue  Operators 

The  Message_Cueue  (figure  19)  is  a 
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Top [Process_ID] 
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Message 
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Figure  19.  Message  Queue  And  Pointers 
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two-dimensional  array  of  message  "frames".  It  is  indexed 
in  one  dimension  by  the  Process_ID  and  in  the  other 
dimension  hy  a  top  and  bottom  pointer.  Insert_Message 
(figure  20)  is  the  primitive  used  hy  Waxe_Up  to  put  a 
message  into  another  process'  message  queue.  The  design 
only  allows  communication  between  processes  of  equal 


security 

class 

since  a  Success_Code 

is  returned 

to 

the 

waking  process 

.  Get_?irs t_Message 

(figure  21) 

is 

the 

primitive 

used 

by  Block  to  retrieve 

messages 

from 

the 

message 

queue 

.  If  the  queue  is 

empty,  the 

message 

"Queue_Zmpty"  is  returned. 

6 .  Non-Discret ionary  Security  Module 

The  key  to  implementing  a  particular 
non-di scretionary  security  policy  is  in  one  module.  Ey 
representing  the  policy  as  a  partially  ordered  lattice,  an 
interpretation  algorithm  can  be  written  to  make  a 
comparison  between  two  labels  and  return  a  relationship. 
The  relationship  can  b~e  equal,  less  than,  greater  than,  or 
not  related. 

The  Non_Discretionary_Security  Module  shown  in 
figure  22  will  determine  the  relationship  of  three 
categories  of  classification  (Secret,  Confidential, 
Unclassified).  As  shown  there  are  no  checks  for 
compartments  (e.g.,  crypto,  nuclear,  etc.).  If  a  complete 
DOD  security  policy  interpretation  is  desired,  the  module 
can  be  expanded.  Since  some  DOD  specifications  require 
orovisions  for  eight  categories  and  sixteen  compartments, 


Insert_Message  Procedure  ( Message_Queue_IB  Integer 

Message  Message_Type ) 

Returns  (Success_Code  Integer) 

Sr.  t  ry 

If  Non_Di sc_Securi ty  ( APT [Process_ID]  .Class , 

APT [Message_Queue_lD] .Class)  =  Equal 

Then 

If  Message_Queue_Bott  om [Message_Queue_ID] 

=  Max__Queue_Length 

Then  If  Message_Queue3Top  [Missage_Queue_ IE]  =  0 
Thee  Succeis_Code  :=  Queue_Overflov 
Else  Message_Queue  Bot tom [Message  Queue_ID]  :=  0 
Message_Queue [Message_Queue_Id , 
Message_Queue_Bottom [Message_Queue_ID] ] 

:=  Message, Process_ID 
Success  Code  :=  Inserted 
Fi 

Else  If  Message_Queue_Bottom[Mes$age_Queue_ID]  +  1 
*  Mess  age _Queue_To p [Message ~Queue_ ID] 
Then  Success_Code  :=  Queue_Overf low 
Else  Message~Queue  Bottom [Message_Queue_ID]  +=  1 
Message'QueuelMes  sage_Queue_lD , 
Message_Queue_Bot  tom [Message_Queue_ID]  ] 

:=  Message ,Process_ID 
Success  Code  :  =  Inserted 
PI 
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Else  Success  Code  :=  Not_Alloved 

FI 

End  Insert_Message 


Figure  20.  Insert.Message  Procedure 
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Get_Firs t_Message  Procedure  (Message_Queue_ID  Integer) 

Returns  ( Fi rst_Message  Missage_Type ) 

Entry 

If  Message_Queue_Top[Message_Queue_ID]  = 

Me s sage _Queue _Bo  t tom [Message_Queue_ID] 

Then  Firs t_Message  :=  Queue_Empty 
Else  If  Message_Queue_Top  [Message_Queue_ID]  = 
Max_Q.ueue_Length 

Then  Message_Oueue_Top [Message_Oueue_ID]  :=  0 
Else  Message3Queue_Top  [Message  Queue_ID]  +=  1 
Fl 

Firs t_Message  Message_Queue [Message_Queue_ID, 
Message_Cueue~Top  [Message  Queue  ID]] 
Fi 

End  First_Message 


Figure  21.  Get_First_Message  Procedure 
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Non_Disc_Security  Procedure  (Class_l  Longword 

Class~2  Longword) 

Returns  (Relationship  Integer) 

Entry 

If  Class_l 

Case  Unclassified  Then 
If  Clas s _2 

Case  Unclassified  Then  Relationship  :=  Equal 
Case  Confidential , Secret  Then  Relationship 

:=  Less_Than 

Else  Relationship  :=  Not  Related 
Ei 

Case  Confidential  Then 
If  Class_2 

Case  Unclassified  Then  Relationship  :=  Greater_Than 
Case  Confidential  Then  Relationship  :=  Equal 
Case  Secret  Then  Relationship  :=  Less_Than 
Else  Relationship  :=  Not  Related 
Ei 

Case  Secret  Then 
If  Class_2 

Case  Unclassified, Confidential  Then 

Relationship  :=  Sreater_Than 
Case  Secret  Then  Relationship  :=  Equal 
Else  Relationship  :=  Not  Related 
Fi 

Else  Relationship  :  =  Not_Related 


End  Non_Lisc_Security 


Figure  22.  Non_Disc_Security  Procedure 
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a  longvord  was  chosen  as  the  data  type  for  representing 
the  labels.  The  32  hits  of  a  longvord  are  more  than 
sufficient  to  represent  all  possible  combinations  of 
categories  and  compartments. 

Similarly,  Privacy  Act  requirements  are  easily 
implemented  in  Non_Discretionary_5ecuri ty  since  they  can 
be  represented  by  a  lattice  structure.  Most  other 
practical  ncn-discreti onary  security  policies  can  be 
implemented  as  well. 

7 .  Inner  Traffic  Controller  Module 

The  Inner_Traf f ic_Controller  provides  the 
multiplexing  of  virtual  processors  to  the  real  processor 
of  the  system.  Tach  loaded  process  will  be  allocated  to  a 
virtual  processor,  implying  that  there  is  a  many  to  one 
correspondence.  In  order  to  manage  these  virtual 
processors,  the  Inner_Traf f ic_Cont roller  has  direct  access 
to  the  machine  hardware.  The  Memory  Management  Unit  and 
processor  state  are  loaded  and  unloaded  by  the 
Inner_Traff ic_Controller ,  thus  accomplishing  the 
multiplexing  to  the  physical  processor. 

In  addition  to  managing  the  virtual 
processors,  the  Inner_Traff ic_Controller  furnishes 
inter-process  services.  Signal  and  Wait  are  used  by 
processes  in  the  Kernel  ring  to  communicate  with  other 
Kernel  ring  processes  a^d  are  primitives  of  the 
Inner_Traf f ic_Control ler . 

The  main  database  used  to  handle  the 


Inner_Traff ic_Controller  functions  is  the 
71rtual_Processor_Table  .  Additionally,  a  software  image  of 
each  MMU  is  maintained  for  every  loaded  process. 

a.  Virtual  Processor  Table 

The  Vir tual_Processor_Table  (figure  23)  is 
indexed  by  the  Virtual_Processor-ID.  Each  virtual 
processor  can  be  in  one  of  three  states:  1)  Running,  2) 
Ready,  or  3)  Waiting.  These  three  states  are  analogous  to 
the  state  of  a  process  and  are  used  for  processor 
scheduling  in  the  same  manner  as  the  Traf f ic_Controller 
used  the  state  of  a  process  for  scheduling  processes. 
After  the  State  field  is  the  Signal_?ending_S witch  which 
functions  precisely  as  the  Wake_Up_Wai ting_Swi tch  for 
preventing  a  race  condition  from  occurring  with  the 
interprocess  communication  primitives.  Priority  is  the 
next  field  which  is  also  analogous  to  the  APT  priority. 

Loc_Processor_State  is  a  pointer  to  the  area 
in  memory  where  the  MMU  software  image  is  maintained  as 
well  as  the  'save  block'’  for  the  machine  state  of  the 
virtual  processor  when  it  is  ready  or  waiting.  Figure  24 
is  an  example  of  the  format  of  the  MMU  image. 

b.  Kernel  Interprocess  Communication  Primitives 

Signal  and  Wait  function  in  the  sane  manner  as 

31ock  and  Wake-Up.  The  chief  distinction  between  the  pairs 
is  the  degree  of  trust  placed  on  the  correctness  of  use. 
Since  Signal  and  Wait  are  Kernel  primitives  which  are  used 
only  by  process  operating  in  the  Kernel  domain,  the  calls 
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can  be  guaranteed  to  return.  The  same  trust  cannot  be 
placed  on  the  calls  to  Block  and  Wake_Qp  by  processes  in 
the  Supervisor  ring.  The  loop  free  structure  implies  that 
the  Kernel  neither  knows  nor  cares  what  happens  in  the 
outer  domain  for  domains,  if  present).  Yet,  the  Kernel 
must  not  allow  the  security  state  of  the  machine  to  change 
except  in  accordance  with  the  rules  of  the  mathematical 
model.  31ock  is  restricted  to  communication  among 
processes  at  the  same  level.  The  Kernel  must  call  upon 
processes  operating  at  different  security  levels  to 
accomplish  its  task  and  thus  needs  a  different  primitive 
since  systemwide  information  is  being  passed. 

1»ith  one  exception.  Signal  (figure  25)  and 
Wait  (figure  26)  function  in  the  same  manner  as  Wake_Dp 
and  Block  do  in  the  Traff ic_Controller .  Since  the  data 
structures  in  the  Inner_Traf f ic_Controller  function  with 
virtual  processors,  the  S ignaled_?rocess_IB  or  ?rocess_ID 
(input  parameters)  must  be  translated  into  a 
Signaled_?rocessor_ID  or  Processor_ID.  A  one-dimensional 
table  is  maintained  for  this  purpose.  Because  the 
Inner_Traf f ic_Con troller  must  complete  its  task  before  it 
returns  to  the  calling  procedure  and  is  synchronous  to  the 
progress  of  the  process,  the  table  translation  of  process 
to  virtual  processor  works.  The  Idle  processes  will  never 
try  to  Signal  or  Wait  and  will  never  cause  the  scheduling 
algorithm  to  be  executed. 

It  is  possible  for  the  Idle  process  to  be 
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Signal  Procedure  ( Signa led_Procsssor_ID  Integer 

Signa l_Message  Message_Type ) 

Returns  ( Success_Code  Integer) 

Entry 

Do 

S ignaled_Processor_ID  :=  Map( Proces s_ID ) 

Success_Code  :=  Insert_Message(SignaIed_Processor_ID  Message) 
If  Success_Code  =  Queue_Over f low 
Orif  Success_Code  =  Not_Allowed 
Then  Exit 

Else  VPT  [Signaled_?ro ces sor_IDl .Signal_Pending_Switch  :=  On 
If  VPT  [Signaled_Processor_ID]  .State  =  Waiting 
Then  VPT  [Signaled_Processor_ID]  .State  :  =  Ready 
Enter  Ready  Queue  (Signaled_?rocessor  ID) 

Ti 

VPT  [?rocessor_ID] .State  =  Ready 
Enter_Ready_Queue ( Proces sor_ ID) 

Sched_Ready_?rocessor 

Pi 

Od 

End  Signal 


Figure  25.  Signal  Procedure 
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Wait  Procedure 

Returns  (Proce$s_ID  Integer 

Signal_Message  Message_Type ) 


Entry 

?rocessor_ID  :=  Map(Process_ID ) 

If  VpT  [?rocessor_ID] .Signal_Pending_Swltcn  =  On 
Then  VPT  [?rocessor_ID] .Signal_?ending_Switch  :=  Off 
Else  VPT  [?rocessor_IDl .State  :=  Waiting 
Sched  Ready  Processor 
?i 

Signal_tfessage  :=  Set _? ir st_Sig_Mes s ( S ig_Cueue [Processo r 
End  Wait 


Figure  26.  Wait  Procedure 


scheduled  on  each  virtual  processor  in  the  storage  s/stem. 
When  that  occurs  the  real  processor  will  come  to  a 
standstill,  executing  a  Halt  instruction.  At  first  glance 
this  would  seem  to  be  an  error  condition,  but  in  reality 
it  is  not.  Since  the  Archival  System  is  driven  by  external 
events  this  may  at  times  be  a  normal  state.  When  a  request 
is  made  from  a  Host,  the  interrupt  handler  (an  I/C_Manager 
entry)  will  Signal  (via  the  I nner_Traf fic_Cont roller )  the 
appropriate  process  and  cause  the  scheduling  algorithm  to 
be  executed. 

c.  Service  Functions 

All  of  the  functions  of  the 
Inner_Traff ic_Controller  are  called  from  the  Kernel  ring. 
Add_Seg,  Delete_Seg,  Load,  and  Unload  are  service  calls  to 
support  the  Segment_Manager .  These  are  hardware  dependent 
functions  and  the  details  of  their  design  will  be 
influenced  by  the  specific  characteristics  of  the  rtMU  and 
CPU  hardware.  Add_3e*  calces  an  entry  into  an  MMU  hardware 
descriptor  and  also  the  mmu  software  image.  This  call  is 
made  from  Maae_Known  and  will  only  set  up  the  descriptor. 
Since  the  segment  has  not  been  Swapped_In  at  this  point, 
the  address  fields  of  the  descriptor  will  be  null  and  the 
attribute  field  of  the  descriptor  will  be  set  to  inhibit 
the  CPU  from  malting  access. 

Delete_Seg  is  called  from  terminate  and  is 
-eqilred  to  remove  an  entry  from  the  MMU  and  the  software 
-*re.  '.cad  will  place  the  absolute  location  of  the 
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segment  "base  address  into  the  MMU  and  change  the 
attributes  to  allow  the  CPU  access.  Unload  removes  the 
segment  base  address,  inhibits  CPU  access  again  and  also 
retrieves  the  changed  bit  from  the  attribute  field.  This 
changed  bit  is  set  when  a  segment  is  written  and  is  used 
by  the  Memory_Manager  to  decide  if  the  segment  can  be 
overwritten  or  if  it  must  be  written  back  to  secondary 
storage,  A  variant  of  Load  and  Unload  is  needed  by  the 
Memory_Manager  when  doing  a  local  to  global  move. 

Swap_MMU  is  called  from  the  Traf f ic_Controller 
and  is  a  result  of  the  scheduling  algorithm  being 
eiecuted.  In  the  general  case  a  process  swap  would  occur 
on  the  virtual  processor  as  a  result  of  this  call.  In  the 
Archival  Storage  System,  there  are  only  two  processes 
which  are  allowed  to  run  on  a  virtual  processor:  1)  the 
loaded  process  or  2)  the  Idle  process.  An  MMU  swap  will 
still  occur  conceptually  when  the  idle  process  is  loaded 
because  it  has  an  MMU  image  just  as  any  other  process. 
Actually  the  idle  process's  MMU  image  is  exactly  the  same 
as  the  loaded  process,  so  a  physical  swap  does  not  take 
pla ce . 

Other  service  calls  will  be  made  to  the 
Inner_Traf f ic_Controller  from  the  Memory_Manager  and 
t/C_Manager  but  are  not  detailed  here.  Software  faults,  as 
discussed  in  O'Connell  and  Richardson  [5],  are  not  needed 
in  this  design. 

S .  Memory  Manager  Module 


The  Memory_Manager  is  a  non-dis tribute!  Kernel 
process  and  is  responsible  for  managing  the  real  memory 
resources  of  the  system.  The  real  memory  o?  the  system  is 
both  main  memory  (random  access)  and  secondary  storage 
(non-random  access).  The  Memory_Manager  could  be  part  of 
the  distributed  Kernel  in  the  Archival  Storage  System 
since  it  is  designed  for  a  single  microprocessor?  however, 
the  process  abstraction  is  used  to  maintain  the  "family 
member"  character  of  the  design. 

a.  Fernery  Management  Scheme 

The  two  main  tasks  of  the  Memory_Manager  are 
to  bring  segments  into  memory  (In)  or  remove  segments  from 
memory  (Out).  Partitioned  allocation  is  the  scheme 
employed  to  manage  the  memory  resource.  Each  loaded 
process  is  given  a  partition  of  linear  contiguous  real 
core  and  is  required  to  manage  (via  calls  to  5wap_In  and 
Swap_0ut)  the  partition  (its  linear  virtual  core)  in  any 
way  it  chooses.  The  Memory_Manager  checks  each  'In' 
request  against  the  process's  allocation  to  insure  that 
the  allocation  is  not  exceeded  and  to  insure  that 
previously  allocated  memory  is  not  overlayed. 

Vhen  a  shared  segment  is  not  writeabie  (i.e., 
write  permission  has  not  been  given  to  any  process),  the 
design  allows  multiple  copies  (one  per  process)  of  the 
segment  to  exist.  This  frees  the  Memory_Manager  from  the 
task  of  moving  the  segment  to  "processor  global'  memory, 
reouesting  that  all  MMU  images  be  updated,  and  reserves 
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global  memory  for  segments  which  are  shared  and  writeable. 
Furthermore,  the  space  that  can  be  saved  by  having  one 
copy  would  not  be  usable  by  the  processes  which  are 
sharing  the  segment,  since  each  process's  Supervisor  would 
still  have  the  segment  in  its  virtual  core. 

If  a  segment  is  to  be  shared  and  is  writeable, 
then  the  Memo ry_Manager  must  move  it  to  global  memory  [5]. 
This  insures  that  all  users  are  sharing  the  same 
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application.  Segments  are  placed  in  memory  within  the 
appropriate  partition  at  the  location  specified  by  the 
Supervisor  call  to  Swap_In.  A  simple  bit  map  known  as  the 
Memory_Allocation_Map  (figure  27)  is  used  to  indicate 
which  parts  of  memory  are  available  for  use.  Each  bit  of 
the  map  corresponds  to  a  256-byte  page  of  memory.  The  term 
page  is  not  used  here  in  the  classical  sense,  but  is  used 
to  indicate  a  block  of  physical  memory.  Segments  cannot  be 
divided  into  pages  scattered  through  core,  but  must  be 
allocated  to  contisuous  memory  locations. 

The  primary  database  of  the  Memory_Manager  is 
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the  Active_Segment_Table .  It  provides  the  Memory_Manager 
with  the  information  necessary  for  managing  all  segments 
in  the  system  which  are  active. 

b.  Active  Segment  Table 

There  are  two  sections  of  the 
Active_Segment_Table  (AST).  That  portion  of  the  AST  which 
contains  systemwide  information  is  known  as  the 
Global_Active_5esment_Table  (S_AST).  Every  active  segment 
in  the  system  will  have  an  entry  in  the  G_AST.  The 
Memory_Manager  also  maintains  a  portion  of  the  AST  per 
physical  processor  as  the  Local_Active_Segment_Table 
(L_AST).  Only  those  segments  active  within  the  physical 
processor  will  be  in  the  L_AST. 

When  a  segment  is  "Pade_Encwn"  it  becomes 
active  and  will  have  an  entry  in  the  G_AST  (figure  29)  and 
in  the  appropriate  L_AST  (figure  29).  The  concatenation  of 
the  segment's  Unlaue_ID  and  the  index  to  the  segment's 
entry  in  the  G_AST  form  the  ASTE_#  which  is  the  "handle" 
passed  by  the  Pemory_fanager  for  identifying  a  specific 
active  segment.  When  the  Memory_Manager  uses  the  "handle" 
to  enter  the  G_AST,  it  uses  the  Entry_#  of  the  ASTE_* 
portion  as  the  index.  In  the  general  case  (e.g.,  demand 
activation/deactivation),  the  Onique_ID  of  the  "handle"  is 
then  compared  with  the  On ioue_ID  found  in  the  G_AST  entry. 
If  the  identification  check  results  in  a  mismatch,  the 
G_AST  must  be  searched  using  the  Unique_ID  as  a  key  to 
find  the  correct  entry.  This  procedure  is  necessary 
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Figure  28.  Global  Active  Segment  Table 
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because  it  is  possible  that  a  segment's  entry  could  be 
moved  in  the  G_AST  before  all  processes  could  be  notified 
of  the  new  ASTT_#.  If  this  occurred  and  a  check  was  not 
made,  an  unauthorized  access  could  then  take  place.  If  the 
match  is  successful  when  first  checked,  the  proper  entry 
has  been  found.  In  this  design  all  known  segments  for  all 
processes  are  active  so  this  problem  cannot  occur. 

Since  the  G_AST  is  a  systemwide  resource  a 
lock  must  be  used  on  the  G_AST  to  prevent  a  race  condition 
from  occurring  [11].  The  mechanism  used  in  the  design  is  a 
locked/unlocked  flag.  Synchronization  on  the  lock  is 
inherent  in  the  functioning  of  the  Memory_Manager 's 
Signal_Message_Queue .  Note  that  this  mechanism  will  not 
work  if  the  design  is  extended  to  include  more  than  one 
processor  in  the  system  sharing  the  single  S_AST. 

The  Global_Address  field  is  used  only  if  the 
segment  is  located  in  global  memory.  If  it  is  null  the 
address  can  be  found  in  the  L_AST.  The  Connected_?rocesses 
field  is  a  bit  map  signifying  which  processes  currently 
have  the  segment  active. 

The  Written  flag  is  used  to  retain  a  written 
bit  when  a  process  Swaps_0ut  a  segment  which  is  shared  and 
writeable.  Tor  example:  Processes  A  and  3  are  sharing  a 
segment  and  Process  A  has  write  permission.  A  has  written 
in  the  segment  and  now  wants  to  deactivate  the  segment. 
Process  3  is  still  using  the  segment.  When  A  requests  the 
Deactivate,  the  Written  bit  is  passed  to  the 
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Memory_Manager .  But  since  B  continues  to  use  the  segment, 
the  Memory_Manager  will  only  reset  Process  A's  flag  in  the 
Connected_Process  field.  The  Written  bit  is  then  logically 
ORed  with  the  G_AST_Writ ten_Tlag.  When  B  then  Deactivates 
the  segment,  the  Written  bit  it  passes  indicates  that  a 
write  has  not  taken  place.  An  error  would  have  occurred  if 
the  Written  bit  from  Process  A  had  not  been  saved  since 
the  Memo ry_Manager  does  not  write  an  unmodified  segment 
back  to  secondary  storage. 

The  Writeable  flag  is  set  whenever  any  process 
has  write  access  to  the  segment.  This  is  the  key  flag  for 
deciding  (at  the  time  activation  is  requested)  if  the 
segment  must  be  placed  in  global  memory.  It  cannot 
conveniently  be  used  to  provide  an  alternative  to  the 
scenario  presented  above  for  Written.  Consider  that 
Processes  A,  3,  and  C  all  have  writeable  shared  access.  If 
A  Deactivates  after  writing,  the  Memory_Manager  could 
write  back  to  secondary  storage  at  that  time,  (assuming 
the  proper  synchronization  was  used  to  prevent  3  or  C  from 
writing  while  the  transfer  took  place).  Then  when  3  or  C 
Deactivated  after  writing,  another  write  to  secondary 
storage  would  take  place.  Thus  at  least  one  unnecessary 
action  took  place. 

The  A1 ia s_Tab le_ASTE_#  will  be  null  unless  the 
segment  is  a  mentor  segment.  Whenever  a  mentor  segment  is 
made  active  its  Alias_Tatle  segment  is  made  active  at  the 
same  time  and  will  be  assigned  an  A5TE_*.  (The  Alias_Table 


is  a  Memory_Manager  object.  The  Alias-Table  is  actually 
implemented  as  a  collection  of  segments.) 


In  the  general  case  with  demand 
activation/deactivation,  the  #_Entries_Active  is  a  field 
which  is  used  for  Alias_Table  entries  only.  An  Alias_Table 
segment  must  remain  active  as  long  as  any  of  its  entries 
are  active,  although  it  need  not  remain  in  main  memory. 
The  #_Entries_Active  is  a  counter  which  is  incremented  any 
time  an  Alias_Table  Entry  is  activated  and  decremented 
when  an  Alias_Table  Entry  is  deactivated.  Thus  the 
Alias_Table  frame  can  be  deactivated  only  when  the 
Connected_Processor  map  of  the  mentor  segment  and  the 
#_Entries_Acti ve  both  become  zero  or  null.  (Note  that  the 
Connected  Processor  Map  of  the  Alias_Ta'ole  segment  will 
always  show  only  the  physical  processors  whose 
Memory_Manage r  has  the  Alias_Table  in  its  address  space.) 
In  this  design  all  known  segments  are  active  so  these 
explicit  checks  upon  deactivation  are  not  required. 

The  remaining  field  of  the  G_AST  is  the 
?age_Table_Add ress .  The  ?age_Table_Address  is  the  location 
in  secondary  storage  of  the  page  table.  The  page  table  in 
turn  provides  the  location  of  the  segment. 

The  L_AST  portion  of  the  AST  is  maintained  per 
physical  processor  and  should  not  be  confused  with  a 
distributed  data  structure  since  the  L_AST  is  a 
Memory_Manager  data  structure  and  not  part  of  the 
distributed  Kernel.  It  is  searched  by  Virtual  Processor  ID 
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and  segment  Unique_ID.  The  remaining  four  fields  are 
Access,  Absolute_Address ,  Size,  and  Segment_#.  The  Access 
is  the  read  or  read/write  access  of  the  segment  available 
for  use  in  moving  between  local  and  global  memory.  The 
Absolute_Address  is  the  location  of  the  segment  in  main 
memory.  If  Absolute_Address  is  null,  the  segment  is  on 
secondary  storage  and  has  not  been  moved  to  main  memory, 
c.  Aliasing  Scheme 

The  Memory_Manager  also  provides  the  aliasing 
service  for  the  system.  Each  segment  which  exists  in  the 
Archival  Storage  System  has  a  Unique_ID.  This  Unique_ID  is 
an  integer  which  uniauely  identifies  each  segment.  It  is 
chosen  from  a  large  list  of  integers.  Since  the  data  type 
is  a  longword,  the  list  contains  more  than  four  billion 
unique  integers.  To  prevent  a  communication  path  from 
existing  when  a  segment  identification  must  be  passed  out 
of  the  Kernel,  an  alias  is  provided  which  virtualizes  the 
Unique_ID.  When  a  process  wishes  to  create  a  new  segment, 
it  must  pass  the  Kernel  a  Mentor_Segment_#  and  a  desired 
Entry_#.  The  mentor  segment  can  be  any  segment  the 
Supervisor  wishes,  but  an  entry  for  the  mentor  must  be  in 
the  Known_Segment_Table  of  the  process.  The 
Segment_Manager  then  looks  up  the  A5TE_#  of  the  segment 
and  Signals  the  Memo ry_Manager  with  the  ASTE_#  and 
Entry_#.  The  Menory_Manager  maintains  a  flat  file  system 
known  as  the  Alias_Table  (figure  30)  which  is  systemwide. 
Every  active  mentor  segment  has  an  ASTE_#  for  a  segment  of 
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the  Alias_Table.  When  the  Memory_Manager  receives  a  Signal 
which  requires  use  of  the  Alias_Table,  the  Memory_Manager 
brings  the  appropriate  Alias_Table  segment  into  memory. 
The  5ntry_#  is  then  used  as  an  index  into  the  Alias_Table 
where  the  Memory_Manaser  can  determine  the  Unique_ID  and 
physical  attributes  of  the  indexed  segment.  A  segment 
exists  for  each  entry  in  the  Alias_Table. 

The  attributes  found  in  the  Alias_Ta'ole  are 
the  segment  Size,  the  location  of  its  secondary  storage 
Page_Table,  the  segment  Access_Class,  and  the  secondary 
storage  page  table  of  its  Alias_Table  segment  if  it  is  a 
mentor  segment.  AliasJTable  storage  is  allocated  when  the 
first  reauest  for  an  Alias_Table  entry  is  made,  and  is 
deallocated  whenever  the  segment  is  empty.  The 
Memory_Manager  will  not  honor  a  request  to  delete  a 
sesment  if  it  has  an  Alias_Table  segment.  If  this  deletion 
were  allowed,  storage  space  would  be  lost  forever  since 
the  Alias_Table  segment  of  the  mentor  segment  and  any 
segments  referred  to  by  that  Alias_Table  segment  would  not 
be  recovered. 

d.  Storage  Allocation 

The  !“!emory_!lanager  is  responsible  for 
controlling  storage  media  as  well  as  main  memory.  The 
storage  hardware  for  this  design  is  anticipated  to  be  a 
type  cf  hard  disk  using  the  Winchester  technology. 
However,  the  design  may  be  initially  implemented  on  an 
eight-inch  "floppy”  disk  drive  using  the  IBM  standard. 
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single  density  format.  Using  this  standard,  a  single  disk 
has  77  tracks  of  26  sectors  each  available  for  storage. 
3ach  sector  stores  128  bytes  of  information. 

Since  the  Z8000  hardware  allows  segment  sizes 
in  multiples  of  256  bytes,  it  is  convenient  to  establish  a 
"page"  size  as  256  bytes.  Using  this  scheme,  a  page  can 
then  be  stored  in  two  sectors  of  the  disk.  A  page  then 
becomes  convenient  as  the  size  of  a  page  table.  The  page 
table  is  used  to  record  the  location  of  each  page  of  the 
segment  on  the  disk.  If  the  location  of  each  page  is 
stored  in  unpacked  form,  a  total  of  128  page  locations  can 
be  stored  in  a  page.  Vote,  however,  that  this  scheme  uses 
only  11  of  the  16  bits  which  can  contain  information  (7 
bits  for  the  track  index,  and  4  for  the  sector  index),  and 
can  easily  be  reduced  to  10  bits  since  every  other  sector 
is  not  explicitly  Indexed.  This  means  that  1024  pages  can 
be  addressed  by  one  page  of  a  ?age_Table  and  is  adeouate 
to  store  the  maximum  size  segment  (256  pages)  allowed  by 
the  Z 8000  hardware. 

A  free  page  bit  map  is  needed  in  order  to 
record  which  pa^es  on  the  disk  are  available  and  which  are 
allocated.  This  will  also  reouire  one  page  on  the  disk. 
This  scheme  allows  the  disk  space  to  be  allocated  to 
segments  from  the  "free  list"  and  does  not  require  complex 
compaction  algorithms.  If  other  forms  of  storage  media  are 
used  they  can  be  easily  adapted  to  this  scheme. 

9.  Input_Output  f*anae>er  Module 
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The  I/C_Manager  is  the  non-dis trihuted  Kernel 
process  which  is  concerned  with  moving  information  across 
the  boundaries  of  the  Archival  Storage  System.  It  manages 
the  input  and  output  ports  of  the  system  as  a  resource  in 
much  the  same  way  as  the  Memory_Manager  handled  the  memory 
resource.  The  I/0_Manager  would  use  an  Attach_Table  to 
virtualize  the  system  ports.  While  the  I/0_Manager  is  a 
process  in  the  general  case,  it  can  be  designed  and 
implemented  as  a  distributed  Kernel  function. 
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III.  CONCLUSION  AND  FOLLOW  ON  WORK 


The  detailed  design  of  the  Security  Kernel  for  a  data 
warehouse  has  been  presented.  This  design  is  suitable  for 
implementation  on  a  Zilog  Z3000  microprocessor-based 
system.  A  minimal  subset  of  a  family  of  secure  operating 
systems  has  been  demonstrated  to  exist  and  can  be 
implemented  on  microprocessor  hardware  which  is  available 
today.  This  design  also  shows  the  feasibility  of  an 
Archival  Storage  System  that  can  be  the  nucleus  of  a 
distributed,  multi-microprocessor  computer  system  by 
providing  archival  storage  with  multilevel  security. 

The  design  illustrates  the  utility  of  modern  software 
engineering  techniques.  A  loop-free  structure  was 
maintained  as  a  design  goal,  preserving  the  ability  to 
modify  a  module  without  introducing  change  in  any  other 
module.  An  explicit  process  structure  simplifies  the 
design  for  asynchronous  functions.  Functionality  of  this 
family  member  can  be  extended  by  including  additional 
primitives  from  the  larger  set  of  primitives  described  by 
O'Connell  and  Richardson  [51  . 

Security  of  information  was  a  primary  goal  throughout 
the  design  process.  A  mathematical  model  was  used  as  a 
foundation  for  the  Kernel  to  insure  properly  designed 
security.  A  multilevel  security  capability  is  included  for 
the  storage  system.  Furthermore,  on  this  base  a  complete, 
multilevel  secure,  distributed  "system”  can  be  constructed 
with  the  storage  system  as  the  only  component  requiring 
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multilevel  security. 

While  designed  for  a  single  microprocessor  with  memory 
management  unit  support,  the  structure  of  the  high  level 
design  which  allows  configuration  independence  was 
preserved.  The  same  concepts  for  reducing  bus  contention 
in  a  multiprocessor  system  while  providing  data  sharing 
were  used  and  can  be  easily  extended,  e.g.,  for  increased 
processing  capacity  to  serve  a  large  number  of  higher 
bandwidth  hosts  . 

Implementation  of  the  Archival  Storage  System  is  an 
area  for  further  work.  The  distributed  Kernel  data 
structures  and  procedures  are  described  in  this  thesis. 
Additional  effort  will  produce  compilable  implementation 
code  and  from  this  code  generate  a  loadable  system.  The 
Kernel  non-distributed  processes  for  I/C  and  physical 
memory  management  have  been  briefly  presented  and  more 
detailed  design  will  be  needed  prior  to  implementation. 
The  Archival  Storage  System  design  is  a  minimal  family 
member.  Additional  services  to  the  Supervisor  and 
generalization  of  the  simplifying  assumptions  (e.  g.,  to 
interface  to  multilevel  hosts)  are  major  areas  where 
continued  research  is  indicated. 

After  implementation  of  the  storage  system, 
substantial  work  is  necessary  in  performance  evaluation. 
Hardware  choices  have  been  primarily  left  to  the 
implementor.  Since  many  of  the  software  design 
implications  on  efficiency  are  unknown  at  the  present 
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time,  fine-tuning  of  both  hardware  and  software  will 
result  In  better  system  performance. 
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APPENDIX  A  -  GATE  KEEPER  LISTING 


Gate_Keeper  Procedure 
Type 

Parameter_Table_Entry  Record  [Function_Address  Longvord 

N0_Of _?arafneters  Integer 
Para_I_Length  Integer 
Para_2_Length  Integer 


?ara_n_Length  Integer! 

Local  Unitialize  local  variables! 

Valid  :=  1 
Invalid  :=  0 
Index  :=  8 

?araneter_Table  Array  [Max_Function_Code 

?arameter_Table_Entry] 

:  =  [  [«Traff  i c_C on t roller >531 ock~Sn try  ,1]  , 
[<<Traf fic_Cont roller >>Wake_Up_En  try f 3!  , 
[<<Segment>!anager>>Creat  e_Entry  ,  5]  , 
[<<Segment_Manager»Delete_Entry ,  3]  , 
[<<3egment_Manager>>Make_Known_Zn t ry ,6! , 
r<<3egmen t "Manager >>Terminate_En try , 2] , 
[<<Segment  "Manager  »Svap_In_Entr y , 3 J  , 
[<<Segmen  t_Manager>>Swap_Out_Entry ,2! ] 


Entry 

DI  NVI.VI 
PUSH  ORR14.R0 
PUSH  0RR14.R1 
PUSH  0RR14 ,R2 
PUSH  0RR14.R3 
PUSH  0RR14.R4 
PUSH  0RR14 ,R5 
PUSH  0RR14.R6 
PUSH  0RR14.R7 
PUSH  0RR14 ,  R8 
PUSH  0RR14.R9 
PUSH  0RR14 , R10 
PUSH  0RR14.R11 
PUSH  0RR14 , R 12 
PUSH  0RR14.R13 
LDCTL  R2 , NSPSEG 
LDCTL  R3, NSPCFF 
PUSH  0RR14.R2 
PUSH  9RR14.R3 
El  N  VI  ,  VI 
VALIDATE:  DO 


{Disable  interrupts! 

!Save  user  registers! 


!Save  user  stack  pointer! 


{Enables  interrupts! 

!Check  location  of  arguments  for  user 
read/write  access! 


LDL  «DIST_XERNEL  ID>>ARGUMENT  POINTER, RR2 
CALL  CHECK_ADDRESS_SPACE 
!Get  return  value! 

LD?  RH0,«DIST_KERNEL  ID>>VALIDITY  CODE 
LDB  RH1, VALID 
CPE  RH1 , RE0 

IF  NE  THEN  EXIT  FROM  VALIDATE  IReturn  if  invalid! 
ELSE  LDL  RR2 ,  «DIST  KERNEL  ID>>ARGUMENT  POINTER 
LD3  RH0, INDEX 
FI 
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M07S_STACK:  DO  fMove  argument  list  to  Kernel  work  space! 
CPB  RH0,#0 

I?  EC  THEN  POP  R4.0RR2 

POSH  0RR14.R4 
D*C  RH0 

ELSE  EXIT  FROM  MOVE  STACK 
FI 

REPEAT  FROM  MOVE  STACK  !Looo  until  all  moved! 

OD 

CALL  FUNCTION:  DO 

LD  FUNCTION_CCDE ,0RR14 (*24 )  IRetrieved  from  system  call 

instruction  on  system  stack! 

LD  R6, MAX  FUNCTION  CODE 
C?  R6, FUNCTION  CCDE 

IF  GT  THEN  LD  LDL  RR10,«DIST  KERNEL  ID»MESSA5S  POINTER 
LD  R2 , IN VALID _FUNCTI ON _ CODE 

LD  0RR10 (0 ) , R2  !Put  error  code  into  message! 
EXIT  FROM  CALL_FUNCTION 
ELSE  LD  R6 ,0RR2( NUMBER  OF  ARGUMENTS) 

ICheck  number  of  oarameters ! 

CP  R6,  FUNCTION  TABLE  [FUNCTION  CODE, NO  GF_ARGUMENTS] 

IF  EQ  THEN  CALL  FUNCTION  TABLE  [FUNCTION  CODE  .FUNCTION] 
ELSE  LDL  RR10,«DIST  KERNEL  ID»MESSAGE  POINTER 
LD  R2, INVALID  ARGUMSNT'L  1ST 
LD  GRR10 ( 0  ) , R2 
EXIT  FROM  CALL  FUNCTION 
FI 
FI 

OD  'END  OF  CALL  FUNCTION  LOOP! 
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!Zero  out  user  argument  list! 


LDB  R31, INDEX 
ZERO_OUT:  DO 

CP  RH1,#0 

IF  NE  THEN  POP  R2.0RR14 
DEC  RH1 

ELSE  EXIT  FROM  ZERO  OUT 
FI 

REPEAT 

OD 

LDL  RR8,«DIST  KERNEL  ID»MESSAGE  POINTER 
LDL  RR4 ,0RR14( N STACK _POI NTER ) 

LDB  RH2 , #0 
LDB  RH1 , #8 

MOVE  RET  MSG:  DO  !Put  message  'back  in  user  area! 
CP  EH1,*0 

IF  NE  THEN  LD  R2,0RR8(RH6) 

PUSH  0RR4.R2 
INC  RH2 
DEC  RH1 

ELSE  EXIT  FROM  MOVE  RET  MSG 
FI 

REPEAT 

OD 

OD  ! END  OF  VALIDATE! 

DI  NMI , VI  iDisable  interrupts! 

POP  R3.9RR14  ! Restore  user  registers! 

POP  R2 , ORE 14 
LDCTL  NSPSEG ,R3 
LDCTL  NSPOEE ,R2 
POP  R13.0RP14 
POP  R12 , 0RR14 
POP  R1 1 , 0RR 14 
POP  R10.0RF14 
POP  R9 , 0RR14 
POP  R8.0RR14 
POP  R7.0RR14 
POP  R6 , 0RR14 
POP  R5,0RR14 
POP  R4.0RR14 
POP  R3.0RR14 
POP  R2 , ORR14 
POP  R1.0RR14 
POP  R0.0RR14 

El  NMI , VI  ISnable  interrupts! 

IRET  IRestere  pre-call  cpu  state! 

End  Gate_Keeper 
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APPENDIX  B  -  SUCCESS  AND  ERROR  CODES 


CODE 

ENTRY  POINT 

Invalid_Functi on_Code 

Gate_Keeper 

In va 1 i d_A rg ume nt_C ode 

Gate_Keeper 

Mentor_Seg_Not_Found 

Create_Segment 

Delete_Segment 

Not_Allowed 

Create_Segment 

Delete_Segment 

tfake_Knovn 

Wake_Up 

Not_Compatible 

Create_Segment 

Segmen  t_Too_Laree 

Create_Segment 

No_Segment_#_Avail 

Make_Known 

Segment_Found 

Make_Xnown 

Swap_In 

Swap_0ut 

Segment _Not _Xnown 

Terminate 

Segment_In_Core 

Terminate 

Kernel_Segment 

Terminate 

In  valid _Segment_# 

Terminate 

Swapped_In 

Svap_I  n 

Swapped_Out 

Svap_0ut 

Queue_Empty 

Block 

Queue_Overf low 

Vake_Up 

Inserted 

Wake_Up 
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CODE 

Not_Related 
Greater_Than 
Less_Than 
Eq  ual 


ENTRY  POINT 
Non_Di sc_Securi t y 
Non_Disc_Security 
Non_Disc_Security 
Non_Di sc_Securi ty 
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